June 2014 Release Features
- Certificate assets are automatically loaded into the worker sandboxes that run runbook jobs.
- Azure module shipped as part of the service upgraded from v 0.7.2 to v 0.8.0
- Remove from the runbook configuration UX the ability to log Debug records, to avoid a possible exception in PowerShell Workflow.
- Schedules can now be enabled / disabled. If a schedule is in disabled mode, any runbooks associated with it will not run at that schedule’s scheduled times.
- Issue causing job failure for some scheduled runbooks has been corrected (see
post
for the original error)
- General improvements to runbook authoring and testing experience.
- Improved notifications throughout the Automation experience including notifications around job status, importing modules and managing schedules.
- Modified several instances of UX behavior to improve user experience including improved loading notifications and loading time.
How Release Features Affect You
The numbers in this section correspond to the numbers in the release features. Only those which actively change how you use Automation are listed below.
- Before the auto-install certificates feature, you needed to install your certificates onto the host in your runbook:
InlineScript {
# Import the certificate into the LocalMachine
$MgmtCertThumbprint = ($Using:Certificate.Thumbprint).ToString()
if ((Test-Path Cert:\LocalMachine\Root\$MgmtCertThumbprint) -eq $false)
{
Write-Progress "Certificate is not in the local machine certificate store - adding it"
$store = new-object System.Security.Cryptography.X509Certificates.X509Store("Root", "LocalMachine")
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
$store.Add($Using:Certificate)
$store.Close()
}
}
Now, you can delete this snippet from your code and no longer need to include it going forward. If you used the Install-Certificate runbook (which contains this code) to handle cert installation, you can remove
that inline runbook call as well. Keeping this code / inline runbook in your runbook will not cause failures, you just do not need it any longer.
3. You cannot use Write-Debug in your runbooks and should use Write-Verbose instead. Write-Debug is meant to be used only in interactive PowerShell sessions, and this change ensures that you don’t
accidently use interactive features in your runbooks (which are non-interactive).
Beth Cooper
