Powershell Cmdlet from which module?

Powershell is pretty much the scripting language that is in every system administrators bag. One of the problems that I have is that I have installed lots of different Powershell modules on my servers, workstations, VM you name it. Over time you kinda of lose track and end up with differs of different versions of modules on different boxes. As the team I am working in is quite young to scripting we have not really followed a process to write within our scripts to check which version of module people should have installed before executing the script so that the cmdlet will run.

In the meantime you can run this handy command to quickly check what module and the version of  module you need to be able to use that particular cmdlet. Remember the same cmdlet may of been updated in a newer version too to have more features.

So on the machine where your script/cmdlet has run successfully run the following command in Powershell;

Get-Command -type cmdlet get-vm | select ModuleName, version

As you can see from the results you can see that the "get-vm" cmdlet on my machine is from the module "VMware.VimAutomation.Core" and is version "11.0.0.10336080".

On this second example;

Get-Command -type cmdlet start-sleep | select ModuleName, version

The result for cmdlet "start-sleep" is from the module "Microsoft.PowerShell.Utility" and version "3.1.0.0".

As you can see from the examples you will be able to identify if you have the correct module and version installed on your machine to run a particular cmdlet.  

Azure Resource Tag Support

I have been using Azure policy for the pass few months to help audit check if all my resources have the relevant tags that we need applied on. Unfortunately not all resources can be tagged in Azure and you may need to make a few changes so that your compliance report does not report the wrong information for you, especially if your management team have access to view the compliance.

Here are few pointers to help make your compliance report more accurate:

• If your Azure policy is just checking on tags then you should set the mode for the policy to be "indexed". As "indexed" mode will only evaluate resources that support tags and location which will prevent your compliance report to not be shown as non compliance. 

• Use this site reference to help see if a particular resource can be tagged and reported in costing. This will help you to understand that not everything can have a tag to help you with cost reporting. https://docs.microsoft.com/en-us/azure/azure-resource-manager/tag-support

Further information around Azure policy and its mode type can be found here

https://docs.microsoft.com/en-us/azure/governance/policy/concepts/definition-structure

Moving Azure Resources

Whenever you deploy a resource into Azure you have to deploy them into a resource group. Over time you may discover that you need to move the resource to another resource group or even subscription. Example of a move could be, a particular VM now belongs to App B so you need to move it to the resource group where all the App B resources are. 

Now not all resources can be moved to another resource group or subscription so here is this handy article from Microsoft where you can check if the resource can be moved between resource group or subscription. 

https://docs.microsoft.com/en-us/azure/azure-resource-manager/move-support-resources

One key point to remember is that moving the resource does not actual move or change the location of the resource. You are only changing the location of where you are managing the resource from. So if you have deployed a VM in North Europe in resource folder A and decided to move this resource to resource folder B. The VM will continue to run from North Europe but the management of the VM would be from resource folder B.

Below is any article on some key checks before you move the resources and various examples on how to move the resource using the Azure portal, powershell, Azure CLI or REST API.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-move-resources

Powershell cmdlet syntax

Over the years I have been using powershell and Windows Powershell ISE as my default editor. Whenever I was stuck on not knowing the syntax for a cmdlet I would use the Commands windows and find my cmdlet then select Show Details

You will get a expanded menu of all the possible syntax/s that are for the cmdlet. Selecting the question mark then brings up more detailed information such as description, syntax and examples.

There are times where I work straight on the command line and discovered that there are equivalent commands available to help display this information

Get-Command Connect-VIServer -Syntax

This would output the syntax/s the cmdlet can accept

Another useful command to use it 

Get-Help Connect-VIServer -Examples

This would output some examples to help you on how to use this cmdlet

Below are a few more cmdlets which provides further information about a cmdlet which maybe useful

Get-Help Connect-VIServer -Detailed

Get-Help Connect-VIServer -Full

Get-Command Connect-VIServer -ShowCommandInfo

Remember to save your resource pool tree

One of the things that you could lose when you disable DRS for a cluster is your resource pool trees and the settings your resource pools (Memory/CPU reservations etc). Settings such as anti-affinity/affinity, DRS automation level are not included.

With so much automation taking place nowadays it is very easy to script something to enable or disable DRS via PowerCLI. A simple line like this 

To turn OFF DRS :

Get-Cluster -Name "cluster" | Set-Cluster -DrsEnabled:$false

To turn ON DRS :

Get-Cluster -Name "cluster" | Set-Cluster -DrsEnabled:$true

One thing I noticed with this PowerCLI command is that it does not give you an option to save/export your resource pool tree structure and settings. I have seen people asking in VMTN how to use script to export your settings to a CSV file and there are plenty of ways.

I am going to walk through how to backup and restore your resource pool tree via the HTML 5 client and assuming you have set up a cluster already and DRS is enabled

• Log on vCenter via the html client
• Highlight your cluster name and expand on it. With my example you can see that I have two host and two resource pools. I have one VM under Test Resource and a second resource pool called Test Resource 1. On the right-hand side of the window you will see the settings for your cluster. Select the Configure tab, under Services select vSphere DRS. You should now see if vSphere DRS is on or off. Now click on edit.

• Your vSphere DRS switch should be shown as green highlighting that DRS is enabled. Click to flip the switch to turn it off which should be like below. Click OK

• This is the important screen where is warns you about the removal of resource pool and asks you whether you like to save it or not. Remember to click Yes because by default this screen has the No button as default. (Hopefully VMware will change it). By default the file name is saved as cluster.snapshot in your default download location for your browser.

That’s it to save your resource pool tree and settings such as share, reservations and limits for CPU or Memory. Settings such as VM/Host rules, DRS Automation level are not part of the resource pool tree settings so won't be included. You would need to use other PowerCLI commands to extract those information.

The next few steps focuses on restoring those settings back to your cluster. As always there are some caveats around restore.

1. vSphere DRS must be turned ON before you can restore
2. You can only restore a snapshot to the same cluster that it was taken from
3. No other resource pools are present in the cluster

Now on to the process of restore

• Log on vCenter via the client
• Highlight your cluster name and expand on it. With my example you can see that I have two host and the VM is at the root of the cluster. On the right-hand side of the window you will see the settings for your cluster. Select the Configure tab, under Services select vSphere DRS. You should now vSphere DRS is off.  Now click on edit.

• Your vSphere DRS switch should be shown as grey highlighting that DRS is disabled. Click to flip the switch to turn it on which should be like below. Click OK

• You should now see that DRS is turned back on. At the vSphere DRS configuration screen click on Restore Resource Pool Tree

• Click on choose file

 Locate your cluster.snapshot file

• On this screen once check that you have selected the correct file and then click OK

• Now you should see that the Resource Tree is restored as with my example, my VM has now moved back to under Test Resource pool. All the CPU/Memory settings for the resource pools are also restored