Today I am releasing version 3.4 and 4.0 of my Storage Overcommitment PowerShell script and first of all I want to talk about the changes I have made.
-> https://gallery.technet.microsoft.com/Discover-Cluster-Shared-859f133c
Version 3.4 adds support for selecting multiple Hyper-V clusters and will be the GUI version from now on. That said you will use version 3.4 not on a regular basis compared to version 4.0, but I will talk about that later. Assume you are a consultant and you would like to do a quick check on the customer environment, if the storage of the Hyper-V cluster is overcommitted. Then you would use version 3.4.
Version 4.0 adds support also for multiple Hyper-V clusters, but it is the PowerShell workflow version of the script. The PowerShell workflow version can be run in your SMA environment or in your Azure Automation account with a Hybrid Runbook Worker deployment. You can trigger the runbook then with a schedule to run it on a daily basis.
If you are implementing the runbook in your SMA environment or in your Azure Automation account does not matter and does not change the requirements. The requirements are the following ones.
- Automation variable with the FQDN of the VMM management server
- PS automation credential with the credentials of the service account under the VMM management server runs
- Automation variable with the email address of the recipient
- Automation variable with the email address of the sender
- Automation variable with the FQDN of the SMTP server
Run the following lines of PowerShell code on or against your SMA management server to create the required variables and credential object and to import the runbook. The runbook will not be automatically published!
$SMAWebServiceEndPoint='https://srv-3.neumanndaniel.local' $SMAWebServiceEndPointPort='9090' $VMMServer='srv-1.neumanndaniel.local' $VMMServerCredential=Get-Credential Set-SmaVariable -Name 'VMM Server' -Value $VMMServer -WebServiceEndpoint $SMAWebServiceEndPoint -Port $SMAWebServiceEndPointPort Set-SmaCredential -Name 'VMM Server Credential' -Value $VMMServerCredential -WebServiceEndpoint $SMAWebServiceEndPoint -Port $SMAWebServiceEndPointPort Set-SmaVariable -Name 'Email From' -Value 'scvmm@neumanndaniel.de' -WebServiceEndpoint $SMAWebServiceEndPoint -Port $SMAWebServiceEndPointPort Set-SmaVariable -Name 'SMTP Server' -Value 'srv-5.neumanndaniel.local' -WebServiceEndpoint $SMAWebServiceEndPoint -Port $SMAWebServiceEndPointPort Set-SmaVariable -Name 'Email To' -Value 'scvmm@neumanndaniel.de' -WebServiceEndpoint $SMAWebServiceEndPoint -Port $SMAWebServiceEndPointPort Import-SmaRunbook -Path .Get-SCStorageOvercommitmentWorkflow.ps1 -Tags 'SCVMM' -WebServiceEndpoint $SMAWebServiceEndPoint -Port $SMAWebServiceEndPointPort
Use the following lines of PowerShell code against your Azure Automation account to create the required variables and credential object and to import the runbook. The runbook will not be automatically published! One side note here. My Azure Automation account runs under the Azure Resource Manager stack. So the instructions for Azure Automation accounts running under the Service Management stack are a bit different.
$ResourceGroup='Azure-Stack' $AutomationAccountName='Azure-Stack-Automation' $VMMServer='srv-1.neumanndaniel.local' $VMMServerCredential=Get-Credential $AzureAutomationAccount=Get-AzureAutomationAccount -ResourceGroupName $ResourceGroup -Name $AutomationAccountName New-AzureAutomationVariable -Name 'VMM Server' -Value $VMMServer -ResourceGroupName $AzureAutomationAccount.ResourceGroupName -AutomationAccountName $AzureAutomationAccount.AutomationAccountName -Encrypted $false -Verbose New-AzureAutomationCredential -Name 'VMM Server Credential' -Value $VMMServerCredential -ResourceGroupName $AzureAutomationAccount.ResourceGroupName -AutomationAccountName $AzureAutomationAccount.AutomationAccountName -Verbose New-AzureAutomationVariable -Name 'Email From' -Value 'scvmm@neumanndaniel.de' -ResourceGroupName $AzureAutomationAccount.ResourceGroupName -AutomationAccountName $AzureAutomationAccount.AutomationAccountName -Encrypted $false -Verbose New-AzureAutomationVariable -Name 'SMTP Server' -Value 'srv-5.neumanndaniel.local' -ResourceGroupName $AzureAutomationAccount.ResourceGroupName -AutomationAccountName $AzureAutomationAccount.AutomationAccountName -Encrypted $false -Verbose New-AzureAutomationVariable -Name 'Email To' -Value 'scvmm@neumanndaniel.de' -ResourceGroupName $AzureAutomationAccount.ResourceGroupName -AutomationAccountName $AzureAutomationAccount.AutomationAccountName -Encrypted $false -Verbose Import-AzureAutomationRunbook -Path .Get-SCStorageOvercommitmentWorkflow.ps1 -Type PowerShellWorkflow -ResourceGroupName $AzureAutomationAccount.ResourceGroupName -AutomationAccountName $AzureAutomationAccount.AutomationAccountName –Verbose
It does not matter if you are using SMA or Azure Automation the runbook will always run at your on-premises environment, because Azure Automation is using the Hybrid Runbook Worker feature. The only thing that differs is where your automation engine sits and yes you cannot integrate Azure Automation into the Windows Azure Pack Administrator portal. The result on both automation engines will be the same that you get an output.
Beside that the runbook will create a CSV file in the folder C:SCVMMStorageOvercommitmentReport on your runbook worker with all the details.
The naming convention is Month-Day-Year.csv. After the file is created an email will be sent with the file attached to the specified recipient.
If you want create a schedule to get the report on a daily basis. One important thing when you are using Azure Automation. You have to make sure that you specify the parameter for your schedule where the runbook runs on.
