EcoShell 1.2.5 and a General Update
Today I was able to sneak out the release of EcoShell 1.2.5. This is actually a relatively minor release that introduces export functionality into the Vizioncore vControl product. There is a new common action that will allow users to take any script that we have created out of the box or that they have manually created, and allows it to be plugged into vControl as a workflow step. There is no other functionality that has been added to the 1.2.5 release.
That being said, with the new year, FINALLY comes new budget, which means we are going to really start pushing the limits of EcoShell as we wrap up the 1st quarter and kick off the 2nd. We have a lot of things we want to provide over the next several months, but wanted to highlight the key 1.3 features here:
- Complete re-write of the PowerPack to accommodate PowerCLI 4.0 Update 1 - This means we no longer need to write our own session management code (YEAH!). This means our scripts are much more portable and can be copied/pasted to a standalone script and will just run. This is also setting us up for a future release to have a script scheduler/export feature built right into the product.
- Beta Name Going Away (YEAH!) - With 1.3 we will finally remove the beta connotation. After racking up close to 20,000 downloads in a very short period of time with minimal bugs or issues, we’re happy to finally get rid of the beta label!
- Parity with all current PowerGUI features - We will no longer have feature differences between PowerGUI and EcoShell. Items such as charts will finally make their way into PowerGUI, and EcoShell will finally get Write-Progress support.
- A Few More Tasks that Suck - We’re going back through the old “Tasks that Suck” list and adding a few new features in (as well as FINALLY fixing the few false-positives showing up in the Orphaned VMDK Files script)
I’m excited for the next few months here as I can finally ramp up development efforts again and add significant new features and enhancements to the product for our faithful customers!
-Scott
Setting up vRanger Pro for Remote PowerShell Access
One of the things that I’ve learned while playing with the vRanger Pro PowerPack is that our developers have built in a way to remotely connect to the vRanger Service while using PowerShell. This actually allows us to use PowerShell and Virtualization EcoShell to create a client utility that can interact with the vRanger Server. With the flexibility that Virtualization EcoShell provides, it is easy to start thinking of many invaluable use-cases for using Virtualization EcoShell alongside vRanger Pro.
To get started, you must make a few quick configuration changes on the vRanger server. First go into the X:\Program Files\Vizioncore\vRanger Pro\PowerShell directory and modify the vRanger.API.exe.config file using a text editor.
Find the following line:
<endpoint address=”http://localhost:2480/VAPIHost.svc” binding=”wsDualHttpBinding”
Replace the localhost in the file with the IP Address of the vRanger Server.
Next, you need to modify the client file, which resides in the same directory. Open the vRanger.API.PwerShell.dll.config file.
Find the following line:
<endpoint address=”http://localhost:2480/VAPIHost.svc” binding=”wsDualHttpBinding”
Again, replace localhost with the IP Address of the vRanger Server.
You must now restart the vRanger services on the server. I’ve personally had the best luck rebooting the vRanger server, but realize this may not be possible in all instances. vRanger is made up of 3 services that should be restarted for this change to take effect.
You may now copy the entire X:\Program Files\Vizioncore\vRanger Pro\PowerShell directory and move it to any system that has Windows PowerShell installed. Either Version 1 or Version 2 of PowerShell will suffice. Once you have the directory copied over, simply open up a standard Windows PowerShell prompt and navigate to the vRanger PowerShell directory. Type the following command to launch the vRanger Pro console for the first time:
./vRangerConsole.ps1
This command will register the proper components and allow you to add the Vizioncore vRanger Pro PowerShell library into Virtualization EcoShell. This will also allow PowerShell to interact remotely with your vRanger server to create a client-server architecture using the vRanger Pro Cmdlets!
Jump Start with Virtualization EcoShell Webinar Online Now
Last week I had a chance to do a second Jump Start webinar for EcoShell. For this second webinar, I definitely got to dive deeper into the product and even show off some of the things I am working on for a vRanger Pro PowerPack! For those that may have missed the live webinar, the recording is now available online here.
Dutch VMUG Today - Plus a Surprise!
I’ve been looking forward to today for a few months now. Today is one of the premier European virtualization events, the Dutch VMUG. I attended this event 2-3 years ago and I can honestly say this is the single most technical virtualization event out there. In addition, I have a chance to meet up with some of the best minds in the virtualization space.
One other reason I am really looking forward to today is that I get to present with Eric Sloof on Virtualization EcoShell. Eric will be doing a great presentation on the product and I will come in for the last 10-15 minutes and show off a feature that NO ONE besides myself has seen yet, not even anyone within Vizioncore… A sneak preview of the vRanger PowerPack for Virtualization EcoShell!
This is a very exciting day and I look forward to seeing everyone at the event!
PowerCLI 4.0 U1 = Awesomeness
So I missed the boat because I was traveling yesterday, but Carter and the VMware Team released the 4.0 U1 version of PowerCLI. The most interesting feature to me is not in the fact that there are over 60 new cmdlets (Although that is nothing to balk at). To me, the single greatest feature of the update is the integrated session management that is built in. So, what is it that makes this so great, and why is this important to Virtualization EcoShell users?
Anyone who has found a great script online and decided to copy and paste it into the EcoShell admin console have likely come across the extremely annoying error message “You are currently not connected to any servers.” The example below is a direct copy/paste from the PowerCLI forums from one of Luc Dekens’ many many many responses. The actual code is the following:
Get-VM | select @{N="VMname"; E={$_.Name}}, @{N="ClusterName"; E={($_ | Get-Cluster).Name}}
This is especially annoying when you go and make sure EcoShell says that you are in fact connected. Why does this happen? With the previous releases of PowerCLI, VMware did not maintain sessions globally. Some people often saw this when using functions for establishing a connection and the scope of the connection was lost once the function completed. EcoShell is based on the idea of wrapping commands as functions to execute them based on the input selection from one screen to another, we don’t have a constant PowerShell console in the background simply executing scripts line by line as we click on things.
Now, VMware has globally scoped the connection information and is also storing it into a collection so it can manage multiple connections. This means that we are no longer required to manage this in EcoShell script code. We can now copy and paste to our heart’s content from the web and have accurate results in the EcoShell admin console!
We are planning a January 2010 update to EcoShell, and we will be purging the VMware PowerPack of all our internal session management code meaning not only can you import code from the web, but you will also be able to use our “PowerShell Code” tab to copy and paste code directly into a PS1 to run it as a scheduled task and it will function identically to how it does in the admin console (Visio Diagrams anyone??)
-Scott Herold
Securing Credentials
A question that I am commonly asked when doing PowerShell/EcoShell presentations is a problem that has plagued scripts since time began. ”How do I secure my credentials so I don’t need to supply them in clear-text?” With PowerCLI, VMware enables pass-through credentials of the current logged-on user back to the VCenter server. Let’s assume two things up front:
- Having NO authentication in your script is extremely bad
- We want something that can be used when VCenter is not in an environment or we want to extend beyond virtualization
As an initial test, which is only a proof of concept, let’s take a look at some functions that can help us bring some security into our scripts.
function Set-Password { $pw = Read-Host "Please Enter your Password" -AsSecureString $return = ConvertFrom-SecureString $pw $return } function Get-PassCred { $pass = $key | ConvertTo-SecureString $return = New-Object System.Management.Automation.PSCredential -ArgumentList "UserName",$pass $return } function Get-Connection { Connect-VIServer vcserver.domain.com -Credential $cred Get-VM | select Name } $key = Set-Password $key $cred = Get-PassCred $cred | Out-Host Get-Connection
Let’s take a look at what this does. The first function Set-Password simply prompts a user for their password and reads it directly into a SecureString Variable. Through the use of the ConvertFrom-SecureString Cmdlet, we then take our SecureString and convert it into an Encrypted Standard string. PwoerShell uses the Windows Data Protection API by default to encrypt the returned standard string.
The second function Get-PassCred takes our encrypted Standard String and converts it back into a SecureString. We then create a new PowerShell Credential object that includes a user name of “UserName” and a password made up of our SecureString value. You will need to replace the “UserName” string for this to function in your environment.
The third and final function Get-Connection uses the VMware Cmdlet Connect-VIServer to connect to our environment using our credential object. It then returns a list of VM names in our environment based on the Get-VM Cmdlet from VMware’s PowerCLI.
Again, this is all just a simple POC to show that at now time was the clear-text password ever displayed to you as the user. So how can we take these concepts and more safely deploy scripts in our environment?
One important thing to note is that your converted Standard String value is going to be different every time it is run. The Microsoft Data Protection API uses timestamps as part of its encryption algorithm, so it will likely be impossible to generate the identical key twice. The following standalone script should be your starting point in securing your scripts.
$pw = Read-Host "Please Enter your Password" -AsSecureString ConvertFrom-SecureString $pw #Optional replacement to Line 2 #ConvertFrom-SecureString $pw | Out-File c:\encryptedpw.txt
The above script is identical to our Set-Password function in our proof of concept code. The one optional modification here is that we can either dump out the Standard String to host output, or we can capture it into a text file. I personally prefer dumping it out to a text file as it makes the script code more manageable and easier to understand. You will be using the Standard Screen output or the text file in every script you want to protect. It is also important to note here that the Microsoft Data Protection API ties the specific encryption detail to the user ID that generates it. It will not be possible to create the encrypted Standard String as UserX, and execute it as UserY. You will need to run this script and generate the encrypted Standard String as the user you will be scheduling or executing your scripts with.
Now that we have our Encrypted Standard String, we are all set to create some scripts that use this information. You will need to start every script with the following block of code to take advantage of our Encrypted Standard String (If you choose the Copy/Paste method of your Encrypted Standard String, it will be much longer that what is displayed..I cut mine off for display/formatting purposes.)
$secPass = “01000000d08c9ddf0115d1118c7a00c04fc297eb0100″ | ConvertTo-SecureString
#Optional Replacement for Line 1
#$secPass = Get-Content c:\encryptedpw.txt | ConvertTo-SecureString
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList “VCUserName”,$secPass
Connect-VIServer VCServer.domain.com -Credential $cred
$secPass = "01000000d08c9ddf0115d1118c7a00c04fc297eb0100" | ConvertTo-SecureString #Optional Replacement for Line 1 #$secPass = Get-Content c:\encryptedpw.txt | ConvertTo-SecureString $bStr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secPass) $pass = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($bStr) $pass
Alan Renouf Extends Virtualization EcoShell
When I first started the Virtualization EcoShell, and VESI, the community behind it, I wanted to build a platform that enabled people to extend upon our ideas and truly make the product their own. Alan Renouf is one of the first to have officially done this! Over at his blog, Alan has posted his own VMware PowerPack that extends the capabilities of EcoShell by leveraging some of the MANY scripts he has written.
I encourage everyone to go take a look at the work Alan has been doing. Some of his scripts are simply amazing!
Merci Monsieur Renouf!
-Scott Herold
Virtualization EcoShell 1.2 - Best Practices
Breaking just about every Product Management rule known to man, I decided to take a brief vacation directly following the 1.2 release of Virtualization EcoShell. Now that I am back in town and getting in the mindset of actually working again, I wanted to show off one of my favorite new features of EcoShell, the Best Practice Queries.
The Best Queries provide users with key information about specific configurations within their environment without the need to drill down and find this information. We leveraged our Tasks that Suck blog post and forum post to identify key things that our users run into on a regular basis. Combined with input from the Vizioncore sales team and their customers, we were able to provide a solid list of items right out of the box.
The following Queries are included with the Virtualizaiotn EcoShell 1.2 release:
- WasteFinder - Analyzes VMFS Free/Used space and compares it to Windows Guest Free/Used Space to determine how much space can be freed up using Vizioncore’s vOptimizer Pro. It also links to deeper detail on a per VM basis about it’s overall disk utilization.
- Hosts with NTP Service Stopped - It’s annoying when you start looking through log files and see 1 or 2 ESX servers simply don’t align with anything else just to find out that NTP isn’t running on these servers. This will not only identify these hosts, but will allow you to restart the service as well.
- Hosts with NIC under 1 GB/Sec - Another annoying situation is when you think that a physical NIC is synced up at Gigabit, just to find out someone has the switch port set to 100/Full (Let’s face it, you can still always blame the networking guys). If for some reason your Physical NIC is set statically to something like 100/Full, you can modify this configuration as well.
- Hosts with NIC at Half Duplex - Similar to above. In hindsight, this should be 1 Query with a stupid long name like “Hosts with NIC set under 1GB/Sec or at Half Duplex”. Like the above item, you can also resolve this issue by properly setting the NIC speed.
- VMs with CDROM Connected - Having VMs with a CDROM drive attached prevents VMotion and DRS from working. This Query helps you instantly identify and disconnect any connected CDROM drives. Plus it’s fun to make your cube neighbor mad when he’s in the middle of a giant install.
- VMs with Floppy Connected - Also prevents VMotion and DRS from functioning. At the end of the day…does anyone actually use Floppy disks anymore once a VM is up and running?
- VMs with Limited Memory - This one is my favorite. This finds a NASTY configuration issue in vCenter where memory is set at a level that causes ballooning and swapping for a VM. You can read more about this here on my personal blog.
- VMs with Out of Date Tools - This query identifies all VMs where the tools are out of date. Unfortunately, using PowerShell to update the VMware Tools without a reboot is unreliable and yields very inconsistent results. I have left the “Update Tools” script out of EcoShell for this reason.
- Orphaned VMDK Files - Another popular request. This Query first digs through my VM configurations and identifies all accounted-for VMDK files. It then scans VMFS for all VMDK files and does a simple match. VMs found on VMFS and not in a VM Config are displayed. Again, this one is for identification purposes. I have not found every instance of a possible exception here and would like to ultimately NOT be responsible for deleted production data.
- Raw Device Mappings - Find all RDMs and the VMs they belong to in your environment
- Thin Provisioned VMDKs - Let’s be up front and honest. I DESPISE VMware’s implementation of Thin-Provisioning. You don’t watch what you are doing VERY closely, and it will bring an entire volume down hard. Protect yourself by keeping tabs on what thin-provisioned disks are lurking in your environment.
- Snapshots - Identifies snapshots of varying age such as 7+ or 31+ days old. This also gives you the option to clean them up if you desire.
Make sure you check back later this week when I go over Graphs and Charts!
Virtualization EcoShell 1.2 Released
I’m happy to announce that the 1.2 version of Virtualization EcoShell is officially available for download at TheVESI.org Download Page. We’ve added several new key features that we will be highlighting on our blog over the next several days! Make sure you you download the newest release and give it a shot! Don’t forget to check back here for tips and tricks on how to use the new features over the next few days!
New in the Virtualization EcoShell 1.2 Release
- Charts Tab allowuing users to graph any information presented in the grid view using various chart formats
- Best Practices Filters allow customers to easly perform daily checks of common misconfigurations
- Custom Attribute Manager allows users to view all custom attributes and quickly modify custom attribute values against multiple entities
- Hyper-V PowerPack allowing administrators to manage indivdual Microsoft Hyper-V installations using PowerShell
Virtualization EcoShell 1.2 Release Date
While showing off the great new features of EcoShell 1.2 at VMworld I made the announcement that EcoShell 1.2 would be available by the end of September. Well, obviously the end of the month is here and there is no product yet. In fact, I have received a final signoff from QC yesterday, but after playing with the final build for the last 1.5 days, there are just a few things that I personally feel could use a little bit more polish before releasing it to you guys.
I take the quality of EcoShell VERY seriously, as I put my life into it and ultimately feel it is a reflection of my commitment to our customers. If it means delaying a product because I want to put my best forward, then I’m more than happy to take any necessary heat for it.
I’ve pushed back the release 2 weeks to October 14th so I can clean up some final pieces of the product. It may ship earlier, but I’m trying to avoid slipping beyond October 14th. If there are people out there who want to jump right into the latest and greatest before the 14th, please head over to the following forum post and put in some text along the lines of “Your concepts intrigue me and I’d like to test your software”, and I will happily provide access to the pre-release build starting Monday of next week.
http://thevesi.org/thread.jspa?threadID=10156&tstart=0
Thanks to everyone for their patience. I promise 1.2 will be worth the wait!
