Most every application we run in our datacenters today provides some sort of web-based interface.  The push to move to HTML5, API driven GUIs is a good one – we can access things from anywhere, using any device or browser.  The problem being we are also seeing a push for security, more specifically ensuring that all our web accessible interfaces are running through SSL and only accessed through https. To get around this administrators can go out and purchase a certificate from a trusted authority, however this could get pretty expensive if you start adding up all of the self-signed certificates within your environment.  Another answer – the Microsoft Certificate Server.

When it comes time for your vSphere upgrade there are many different approaches to how you perform the upgrades on your ESXi hosts.   An administrator who looks after a small cluster may update one way, whereas an administrator who looks after an enterprise with 1000s of hosts may opt to go another.  Also, depending on how your environment is deployed you might want to choose one method over another.  Factors such as a whether or not your hosts are managed by a vCenter server, whether or not they are members of a cluster – these things all impact the methods in which you chose to update to the latest version of ESXi.  Certainly, some methods are much more simplistic than others to perform, some offer more advantages when upgrading at scale, and some are more prone to user error – let’s take a look at each method of upgrading our hosts below and discuss the benefits and drawbacks of each…

Picture this – you are working away developing a PowerCLI script that is performing multiple actions – you have it just about complete when you come to a roadblock.  After frantically googling around you find out that this one task you are trying to perform simply cannot be done through PowerShell, yet you know it exists within the local ESXi esxcli command namespace!  This has happened multiple times to me and thankfully, there is a way to access ESXi’s esxcli command namespace without having to leave the comforts of the PowerShell Console. Chances are that if you have been working at all with ESXi you are familiar with the esxcli command – but for those that aren’t let’s take a quick look at what exactly it does.

Creating automation and orchestration requires taking multiple data center components which all speak different languages and chaining them together through one consistent workflow. Now there are a lot of programming and scripting languages that we can use as our orchestration engine such as Java, JavaScript, Perl, etc. – but one of the most common choices within the last 5 years has been PowerShell.

There has certainly been no lack of surprises coming from Redmond over the past year or so. As soon as Satya Nadella took the reins of Microsoft it has seemed like a barrage of Microsoft news hitting the wires – but this news does not fall within the traditional line of Microsoft. Open sourcing .net, open sourcing PowerShell, and finally, providing a means to run MS SQL Server on Linux. Don’t get me wrong – this is great news for the IT world. Cross compatibility, platform-independent – these words are words that excite me. Microsoft has taken notice of the dominance of the cloud, more so, the dominance of Linux within the cloud. Certainly, releasing the ability to take a Linux instance within the cloud and run our SQL Server on it is a step in the right direction – for Microsoft, and for us as IT professionals. Just like PowerShell, the MS SQL Linux deployment supports a limited number of distributions – more specifically Red Hat Enterprise Linux 7 and Ubuntu Server 16.04.

Picture this – you are a systems administrator working at a major banking institution. The security team walks into your office and lets you know that a major update needs to be applied to all of the servers within the institution – not a problem for most organizations, but in the case of a bank, you could have hundreds if not thousands of remote and branch offices.  Sure, we can write scripts to copy out the update files and even execute them remotely from our head office – but the problem most ROBO scenarios are ever-changing – with new offices being created and others closing down all the time.  Keeping track of server names, IP schemes, etc. can be quite a time-consuming process.  Naturally, we want the same updates, patches, and fixes to be deployed everywhere, in the same manner, in order to provide consistency – so having this up to date list available when we need it is key to driving success within our environment.

Ever since PowerShell hit the stage it’s adoption has been increasing dramatically – Finally that Windows-based scripting language that not only appeals to Windows administrators with an easy to use structure but has been widely adopted by the industry surrounding the third-party applications.

VMware has long stopped adding newly released features and functionality into the old С# client in hopes to push their customers into using the vSphere Web Client.  However, even by restricting new features only to the Web Client adoption has been slow – partly due to change, no one likes change, but mostly due to the slowness and the overall sluggishness that is experienced using the flash-based vSphere Web Client.

In 2006 Windows Administrators got their first glimpse into what the world of PowerShell scripting might look like when PowerShell, which was then known as Monad was released under beta conditions to the world. 10 years later we are now into our 5th iteration of the scripting language and have seen a thriving ecosystem form around the Verb-Noun style of automation. PowerShell is a powerful tool and can be an amazing time-saver to for any Windows administrator to know. That said, as with any scripting/programming languages getting started can be a little daunting, especially if you have had no scripting experience to fall back on. Below we will take a look at 5 tips that can save you both time and energy when writing your PowerShell scripts.