Installing PowerCLI 6.5.x on Windows Server 2012 R2 after Find-Module Error

Now that PowerCLI is part of the PowerShell Gallery, you can install it using the native module installer…but there’s a catch. Windows Server 2012 R2 requires a couple of minor updates to get this process underway. You’ll know really quickly if you open up your PowerShell terminal or PowerShell ISE (as Administrator) and try the following command:

Find-Module -name VMware.PowerCLI

The issue is easily solved be deploying a more recent installer for the PackageManagement PowerShell Modules. Download the installer using this link and run the install:

Select the Download within the page once you’re there:

Choose the x64 version (assuming you’re running a 64-bit OS):

Run through the installation and accept the defaults. Nothing significant to worry about with this file as it’s a necessary update for what we need to do.

If you run the Find-Module command again, you’ll see a much better result. You’ll be prompted to update your NuGet components which are used to pull resources from the PowerShell Gallery. Accept the update and then we can keep going:

Time to get back to the issues. Just relaunch your PowerShell terminal or ISE as an Administrator. We are running as Administrator so that we install the module for all users of the server. If you only want to run for your user then run your PowerShell session as your regular user and add -scope CurrentUser to the Install-Module command. Run the following to install for all users:

Install-Module -name VMware.PowerCLI

Now we have to import the module into our session using the Import-Module -name VMware.PowerCLI command:

Just like that, you’re up to date and running the latest and greatest PowerCLI goodness. Happy scripting!

Unable to Delete Empty Elastic Beanstalk S3 Bucket

For those who are doing AWS work among the different projects, you will most likely do some storage on S3 (Simple Storage Service) for templates and logs.  Each AWS service has the ability to write its configuration and logs to S3 and is usually a part of the setup wizard.

Sometimes the permissions set by the AWS wizard may leave you with some challenges.  A common and simple example is when using AWS Elastic Beanstalk.  When you clear out an Elastic Beanstalk configuration, the S3 bucket is left behind because it is not deleted as part of the removal process.

Normally, we just select the bucket and then you can empty it and delete it.  This is what happens instead.  First, select your bucket:


Once selected, we  then choose the Delete Bucket option from the Actions button:


Then we are disappointed by seeing this error message:


Access Denied?!  That shouldn’t be the case.  I’m using an account that does have enhances privileges, and have even attempted it using the root level account for my entire AWS environment.  NOTE:  It’s not recommended to use the root account, but I did try it to prove the point.

Fixing the S3 Bucket Access Denied Issue

The issue is a simple one as it turns out.  Open up the properties for the bucket and click the Edit bucket policy button:


When the bucket is created by the system, it is created with a specific bucket policy that has been set to deny the s3:DeleteBucket action:05-s3-deny-perms

That’s a safety measure so that we don’t accidentally remove the contents which could be driving an active Elastic Beanstalk configuration.  Change the Deny effect to Allow in the JSON editor and save the policy:


Once you’ve saved the policy, go ahead with the Delete bucket process under the Actions menu again, and you will see a much more appropriate response.  This time you will see a Done result in the results window.


This is one of those oddities around saving ourselves from ourselves by making sure we don’t accidentally delete things.  Sometimes we really do want to delete stuff 🙂

VMware tip – Protocol error from VMX

Small tip, big victory. I have weekly snapshots and clones that are scheduled through vCenter. Suddenly one of the clone tasks stopped working and threw this error:

A General System error occurred: Protocol error from VMX.

Hmmm…that’s odd. It’s run fine up to now right? Luckily the fix couldn’t be too much simpler than this.

SOLUTION: Restart the VMware Tools service in the guest machine and restart the task

et voila!