Whether your company has started it or not, companies all over the world are investigating what it would take to become more green.  What does "more green" mean?  Well, it means finding ways to reduce your companies electrical power consumption when you're not needing it.  Many companies have done simple things like ensuring that all desktop PC monitors have a Power Saver timer after 20 minutes of inactivity.  However, many organizations still leave their desktops (and servers) powered on 24x7.

Citrix is attempting to do their part by releasing their Citrix PowerSmart Management Utility.  What is PowerSmart?  In essence, it's a utility that let's an administrator control which servers in a farm are able to be powered off when their session count drops, and then power those servers up on a schedule.  More detail about PowerSmart can be found in Ray Yang's original post announcing PowerSmart.  Some organizatons may not be willing to go down this path as it's a bit risky, but sooner or later all companies are going to find themselves needing to adopt some type of conservation strategy.

I've been discussing the PowerSmart feature with Ray privately and here are a few of my thoughts:

Pros:

- Standardized on WinRM and IPMI (Impact:  By leveraging WinRM Citrix can utilize the latest Microsoft technology for Remote Management of systems without worrying about firewall rules for RPC, etc.  Also, leveraging WinRM with IPMI will allow you to interface with server vendors out of band management products without having to allow directed broadcast wake on lan (WoL) traffic which is typically difficult to get networking folks to modify on their routers).  WinRM by the way is the technology that PowerShell 2.0's remoting is based on.  So you'll probably be rolling it out sooner than later.

Cons:

- It involves a bit of command line scripting for enabling the remote powerdown of systems.

- Since it depends on WinRM, you'll need to roll that out.

- It currently supports only HP Servers that have ILO2 support, so your servers may not be supported.  If that's the case, you could extend it to support WoL by calling a command line WoL utility.  My personal favorite is from Depicus.  Keep in mind with WoL, you'll need to allow Directed Broadcasts of the UDP traffic on whatever port that you've configured your WoL utility to use (typically UDP/7).  Also, you'll need to have the MAC Address and IP Subnet (if its outside of your systems broadcast reach - i.e. a different subnet since routers don't forward broadcast traffic by default).  When you have the MAC address and subnet IP, and you've allowed directed broadcasts then you can launch your WoL utility and wake the remote server.  Assuming, of course, that your server hardware supports WoL.

- It does not currently adapt to requests for load (i.e.  a bunch of users requesting new sessions will not trigger the utility to start powering more servers on).  In fact, the initial version doesn't power the servers on at all.  This type of feature is something being investigated, however.

I'll be investigating this utility further and will blog about further details later.