AutomatedLab Documentation

The AutomatedLabWorker module is a helper module designed specifically for use within the AutomatedLab ecosystem.

Note for users: There is usually no need to execute these cmdlets directly unless you are contributing to the AutomatedLab project itself. They are intended to be called by the core AutomatedLab engine to perform low-level tasks across various hypervisors and cloud platforms.

AutomatedLab (AL) is a tool designed to rapidly set up test and lab environments on Hyper-V or Azure. It can deploy complex environments containing multiple products or single virtual machines.

To use AutomatedLab, you must satisfy two primary requirements:

1. Have the necessary DVD ISO images for the products you wish to deploy.
2. Have access to either a Hyper-V host or an Azure subscription.

The Invoke-LabDSCConfiguration cmdlet allows you to apply PowerShell Desired State Configuration (DSC) to your lab environment. It is a powerful alternative to Invoke-LabCommand for customizing lab machines after deployment.

Key benefits include:

• Automated Complexity Management: It handles authentication, resource copying, and Local Configuration Manager (LCM) configuration (in push mode) automatically.
• Lifecycle Management: Once applied, the configuration is applied every 15 minutes on the lab VMs by default, unless the LCM is reconfigured or the configuration is overwritten.

To use it, you must define a DSC configuration on your host machine and ensure all required DSC resources are available on that host.

AutomatedLab projects use specific XML files for formatting and type extensions. To minimize impact on import times, you should only have one of each file per project. Use the following naming convention:

• Format XML: [ProjectName].Format.ps1xml (e.g., AutomatedLabTest.Format.ps1xml)
• Type Extension XML: [ProjectName].Types.ps1xml (e.g., AutomatedLabTest.Types.ps1xml)

Note: Do not place external help files in the XML folder.

Post-installation activities allow you to run specific PowerShell scripts on a machine immediately after it is installed but before the lab is considered 'ready'. This is useful for complex configurations like populating Active Directory with users or setting up specific application hierarchies.

Use Get-LabPostInstallationActivity to wrap your script and its dependencies, then pass the resulting object to the -PostInstallationActivity parameter of Add-LabMachineDefinition.

You can extend the notification system by adding custom providers. To do this, create a PowerShell script named Send-AL<PROVIDERNAME>Notification.ps1 and place it in the private directory of the AutomatedLabNotifications module.

Your custom provider script must implement a param block with the following two mandatory string parameters:

• $Activity: The activity being reported.
• $Message: The message content to be sent.

param
(
    [Parameter(Mandatory = $true)]
    [System.String]
    $Activity,

    [Parameter(Mandatory = $true)]
    [System.String]
    $Message
)

The TfsBuildWorker role can be added to a machine definition. If no specific properties are provided via the -Properties parameter in Get-LabMachineRoleDefinition, the following defaults are applied:

• Binding: Automatically binds to the first TFS Server detected in the lab.
• Port: Uses port 9090.
• Agents: Deploys 2 build agents.
• Version Matching: Automatically selects the matching installation (TFS 2015 or 2017) based on the TFS server version in the lab.