Octopus Deploy Windows Scheduled Task - octopus-deploy

This question is for all who are using Octopus Deploy to run scheduled tasks.
https://library.octopusdeploy.com/step-template/actiontemplate-windows-scheduled-task-create
Has anyone encountered situation where you have to specify "Start in (optional):" parameter in the scheduled task?
I am wondering if this is possible with Octopus Deploy or if there is any work around?

Octopus deploy community steps are just Powershell scripts with variables. You can edit the Powershell to setup anyone variable for "Start in" path and pass that to the scheduled task. I can give you an example of you need one.
Update
After accuracy looking at the Posh script for the task, I think a better option would be to add a single parameter for the XML file that defines the task parameters and set that inside your Octopus deployment steps. That will give you the most fixability in case you need to provide any other parameters besides the "Start in" parameter.
Update 2
So I wrote a custom Step to do what you wanted, then looked at the community feed, silly me. There is already stemp template to create a scheduled task from XML file. The XML will let you set the working directory. The step template is called "Create Scheduled Tasks From XML" and you can find it at http://library.octopusdeploy.com/step-templates/26c779af-4cce-447e-98bb-4741c25e0b3c/actiontemplate-create-scheduled-tasks-from-xml.
In addition, here is where I was going with the custom step, it's just Powershell:
$ErrorActionPreference = "Stop";
Set-StrictMode -Version "Latest";
function New-ScheduledTask {
param (
[Parameter(Mandatory = $true)][hashtable] $octopusParameters
)
$arguments = #{
TaskName = $octopusParameters['TaskName']
User = $octopusParameters['RunAsUser']
}
if ($octopusParameters['RunAsPassword']) {
$arguments.Password = $runAsPassword
}
if ($octopusParameters.ContainsKey('RunWithElevatedPermissions')) {
if ([boolean]::Parse($octopusParameters['RunWithElevatedPermissions'])) {
$arguments.RunLevel = 'Highest'
}
}
switch ($octopusParameters['Schedule']) {
'Once' {
$triggerArguments.Once = $true
$triggerArguments.At = $runAt
}
'Daily' {
$triggerArguments.Daily = $true
$triggerArguments.At = $runAt
if ($interval) {
$triggerArguments.DaysInterval = $octopusParameters['Interval']
}
}
'Weekly' {
$triggerArguments.Weekly = $true
$triggerArguments.At = $runAt
if ($interval) {
$triggerArguments.WeeksInterval = $octopusParameters['Interval']
}
}
'Startup' {
$triggerArguments.AtStartup = $true
}
'Logon' {
$triggerArguments.AtLogOn = $true
}
}
$actionArguments = #{
Execute = $octopusParameters['Executable']
Argument = $octopusParameters['Arguments']
WorkingDirectory = $octopusParameters['WorkingDirectory']
}
$arguments.Action = New-ScheduledTaskAction #actionArguments
$triggerArguments = #{
TaskName = $taskName
User = $runAsUser
}
$arguments.Trigger = New-ScheduledTaskTrigger #triggerArguments
Write-Output "Creating Scheduled Task - $taskName"
Unregister-ScheduledTask -TaskName $taskName -Confirm:$false -ErrorAction:SilentlyContinue
Register-ScheduledTask #arguments | Out-Null
Write-Output "Successfully Created $taskName"
}
# only execute the step if it's called from octopus deploy,
# and skip it if we're runnning inside a Pester test
if (Test-Path -Path "Variable:octopusParameters") {
New-ScheduledTask $octopusParameters
}

After hitting the same problem I found that schtasks.exe does not take a Working Directory (Start In (optional)) parameter.
I did the following:
Create the scheduled task using the Octopus template (Windows Scheduled Task - Create - With Password)
Saved the scheduled task as XML using PowerShell
Edited the XML to add the working directory
Used the Octopus template (Create Scheduled Tasks From XML) using the updated XML to create the scheduled task.
Here is the PowerShell I used in Octopus to get the scheduled task as XML and insert the Working Directory Node:
$scheduleFolder = $OctopusParameters["ScheduledTaskFolder"]
$scheduleName = $OctopusParameters["ScheduledTaskName"]
$scheduleWorkingDirectory = $OctopusParameters["ScheduledTaskWorkingDirectory"]
$scheduleXmlFileName = $OctopusParameters["ScheduledTaskXmlFileName"]
$installFolder = $OctopusParameters["InstallFolder"]
Write-Output "Connecting to Schedule Service"
$schedule = New-Object -Com("Schedule.Service")
$schedule.Connect()
Write-Output "Getting $scheduleName task in folder $scheduleFolder as xml"
$task = $schedule.GetFolder($scheduleFolder).GetTasks(0) | Where {$_.Name -eq
$scheduleName}
$xml = [xml]$task.Xml
# Parent node
$execNode = $xml.Task.Actions.Exec
# Create WorkingDirectory node
$workingDirectoryElement = $xml.CreateElement("WorkingDirectory",
$execNode.NamespaceURI)
$workingDirectoryElement.InnerText = $scheduleWorkingDirectory
# Insert the WorkingDirectory node after the last child node
Write-Output "Inserting WorkingDirectory node in $execNode.Name node"
$numberExecNodes = $execNode.ChildNodes.Count
$execNode.InsertAfter($workingDirectoryElement, $execNode.ChildNodes[$numberExecNodes
- 1])
# Output the xml to a file
Write-Output "Saving $installFolder\$scheduleXmlFileName"
$xml.Save("$installFolder\$scheduleXmlFileName")
Another option is to save the XML file (with the working directory nodes) as part of your project and just deploy this using the Octopus template (Create Scheduled Tasks From XML).
...
<Actions Context="Author">
<Exec>
<Command>"C:\Program Files\Test Application\Application.exe"</Command>
<WorkingDirectory>C:\Program Files\Test Application</WorkingDirectory>
</Exec>
</Actions>
</Task>

Related

How to trigger Powershell Script when a new File created inside a folder? [duplicate]

I am new to PowerShell and I am trying to use the System.IO.FileSystemWatcher to monitor the presence of a file in a specified folder. However, as soon as the file is detected I want to stop monitoring this folder immediately and stop the FileSystemWatcher. The plan is to incorporate the PowerShell script into a SQL Agent to enable users to restore their own databases. Basically I need to know the command to stop FileSystemWatcher from monitoring as soon as one file is found. Here is the script so far.
### SET FOLDER TO WATCH + FILES TO WATCH + SUBFOLDERS YES/NO
$watcher = New-Object System.IO.FileSystemWatcher
$watcher.Path = "C:\TriggerBatch"
$watcher.Filter = "*.*"
$watcher.IncludeSubdirectories = $true
$watcher.EnableRaisingEvents = $true
### DEFINE ACTIONS AFTER A EVENT IS DETECTED
$action = { $path = $Event.SourceEventArgs.FullPath
$changeType = $Event.SourceEventArgs.ChangeType
$logline = "$(Get-Date), $changeType, $path"
Add-content "C:\log2.txt" -value $logline
}
### DECIDE WHICH EVENTS SHOULD BE WATCHED + SET CHECK FREQUENCY
$created = Register-ObjectEvent $watcher Created -Action $action
while ($true) {sleep 1}
## Unregister-Event Created ??
##Stop-ScheduledTask ??
Unregister-Event $created.Id
This will unregister the event. You will probably want to add this to the $action.
Do note that if there are events in the queue they will still be fired.
This might help too.
Scriptblocks that are run as an action on a subscribed event have access to the $Args, $Event, $EventArgs and $EventSubscriber automatic variables.
Just add the Unregister-Event command to the end of your scriptblock, like so:
### DEFINE ACTIONS AFTER A EVENT IS DETECTED
$action = { $path = $Event.SourceEventArgs.FullPath
$changeType = $Event.SourceEventArgs.ChangeType
$logline = "$(Get-Date), $changeType, $path"
Add-content "C:\log2.txt" -value $logline
Unregister-Event -SubscriptionId $EventSubscriber.SubscriptionId
}
This is the pattern for an event that only performs an action once and then cleans itself up.
It's difficult to effectively explore these automatic variables since they are within the scope of a Job, but you can futz with them by assigning them to global variables while you are sketching out your code. You may also get some joy with Wait-Debugger and Debug-Runspace. In the case of the $EventSubscriber variable, it returns the exact object you get if you run Get-EventSubscriber (having created a single subscription already). That's how I found the SubscriptionId property.
If you want to stop/unregister all registered events you can call
Get-EventSubscriber|Unregister-Event

Task scheduler history - get commands and arguments executed for each task already launched - using Powershell

Anyone would know if it is possible to get from the history task schedules, the command and arguments executed of all the tasks ?
I have a .ps1 script that obtains from the task scheduler history, three values: data of execution, taskname and result code.
$EventFilter = #{
LogName = 'Microsoft-Windows-TaskScheduler/Operational'
Id = 201 #action completed
StartTime = [datetime]::Now.AddDays(-10)
}
# PropertySelector for the Correlation id (the InstanceId) and task name
[string[]]$PropertyQueries = #(
'Event/EventData/Data[#Name="InstanceId"]'
'Event/EventData/Data[#Name="TaskName"]'
'Event/EventData/Data[#Name="ResultCode"]'
)
$PropertySelector = New-Object System.Diagnostics.Eventing.Reader.EventLogPropertySelector #(,$PropertyQueries)
# Loop through the start events
$TaskInvocations = foreach($StartEvent in Get-WinEvent -FilterHashtable $EventFilter){
# Grab the InstanceId and Task Name from the start event
$InstanceId,$TaskName,$ResultCode = $StartEvent.GetPropertyValues($PropertySelector)
# Create custom object with the name and start event, query end event by InstanceId
[pscustomobject]#{
TaskName = $TaskName
StartTime = $StartEvent.TimeCreated
ResultCode= $ResultCode
}
}
$TaskInvocations
Now I need to know what was the command and arguments executed in each task...
I don't find anything... :-( I'm beggining to think that this is not possible...
any idea, please?
Thanks in advance.

How to fix security within WinSCP SFTP scripts in PowerShell with hard-coded passwords

So my organization has tasked me with cleaning up some of the security issues in regards to some automated scripts that have hard coded passwords within the scripts that are running as automated tasks. One such task contains SFTP scripts that export and import files to and from with the password, host name, credentials, port, and everything exposed within the script. As a result, I would like to first see about how to call such credentials within a separate file that can be hidden and two see about encryption and salting it later. But my main focus is getting them out of the script in case traffic is every intercepted. Here is what the PowerShell code looks like:
param (
$localPath = 'E:\FTP\SchooLinks\course_requests.csv',
$remotePath = '/schoolinks_exports/course_planning/course_requests.csv'
)
try
{
# Load WinSCP .NET assembly
Add-Type -Path "C:\Program Files (x86)\WinSCP\WinSCPnet.dll"
# Setup session options
$sessionOptions = New-Object WinSCP.SessionOptions -Property #{
Protocol = [WinSCP.Protocol]::Sftp
HostName = "<domain_name>"
UserName = "<username>"
Password = "<password>"
SshHostKeyFingerprint = "<fingerprint>"
}
$session = New-Object WinSCP.Session
try
{
# Connect
$session.Open($sessionOptions)
# Upload files
$transferOptions = New-Object WinSCP.TransferOptions
$transferOptions.TransferMode = [WinSCP.TransferMode]::Binary
$transferResult =
$session.GetFiles($remotePath, $localPath, $False, $transferOptions)
# Throw on any error
$transferResult.Check()
# Print results
foreach ($transfer in $transferResult.Transfers)
{
Write-Host "Download of $($transfer.FileName) succeeded"
}
}
finally
{
# Disconnect, clean up
$session.Dispose()
}
exit 0
}
catch
{
Write-Host "Error: $($_.Exception.Message)"
exit 1
}
Another one that we have looks like this:
param (
$localPath = 'E:\FTP\TalentEd\SkywardApplicantExportSQL.txt',
$remotePath = '/SkywardApplicantExportSQL.txt'
)
try
{
# Load WinSCP .NET assembly
Add-Type -Path "C:\Program Files (x86)\WinSCP\WinSCPnet.dll"
# Setup session options
$sessionOptions = New-Object WinSCP.SessionOptions -Property #{
Protocol = [WinSCP.Protocol]::Sftp
HostName = "<domain>"
UserName = "<username>"
Password = "<password>"
SshHostKeyFingerprint = "<sha_fingerprint>"
}
$session = New-Object WinSCP.Session
try
{
# Connect
$session.Open($sessionOptions)
# Upload files
$transferOptions = New-Object WinSCP.TransferOptions
$transferOptions.TransferMode = [WinSCP.TransferMode]::Binary
$transferResult =
$session.GetFiles($remotePath, $localPath, $False, $transferOptions)
# Throw on any error
$transferResult.Check()
# Print results
foreach ($transfer in $transferResult.Transfers)
{
Write-Host "Download of $($transfer.FileName) succeeded"
}
}
finally
{
# Disconnect, clean up
$session.Dispose()
}
exit 0
}
catch
{
Write-Host "Error: $($_.Exception.Message)"
exit 1
}
I am familiar with Python and json and calling stuff within a json file similar to the following:
import json
with open('secrets.json','r') as f:
config = json.load(f)
and calling it with (config['object']['nested_element']) within the Python script.
I would like to do something similar with PowerShell, however I have very limited knowledge to PowerShell.
Yeppers, of course, never store creds in clear text in files.
There are several ways to store credentials for use. Secure file (xml, etc..), the registry, or Windows Credential Manager and this is well documented on Microsoft sites, as well as in many articles all over the web and via Q&A's on StackOverflow.
Just search for 'securely store credentials PowerShell'
Sample results...
Working with Passwords, Secure Strings and Credentials in Windows
PowerShell
How to run a PowerShell script against multiple Active Directory
domains with different credentials
Accessing Windows Credentials Manager from PowerShell
Save Encrypted Passwords to Registry for PowerShell
...and/or the modules via the MS powershellgallery.com directly installable from your PowerShell environments.
Find-Module -Name '*cred*' |
Format-Table -AutoSize
<#
# Results
Version Name Repository Description
------- ---- ---------- -----------
2.0 CredentialManager PSGallery Provides access to credentials in the Windows Credential Manager
2.0.168 VcRedist PSGallery A module for lifecycle management of the Microsoft Visual C++ Redistributables. Downloads the supp...
1.3.0.0 xCredSSP PSGallery Module with DSC Resources for WSMan CredSSP.
1.1 VPNCredentialsHelper PSGallery A simple module to set the username and password for a VPN connection through PowerShell. Huge tha...
1.0.11 pscredentialmanager PSGallery This module allows management and automation of Windows cached credentials.
4.5 BetterCredentials PSGallery A (compatible) major upgrade for Get-Credential, including support for storing credentials in Wind...
1.0.4 WindowsCredential PSGallery Management module for Windows Credential Store.
...
#>
So many thanks to #postanote and #Martin Prikryl I was able to figure this out.
You can basically use a config.xml file with contents similar to this:
<Configuration>
<localPath>insert_local_file_path</localPath>
<remotePath>insert_remote_file_path</remotePath>
<Protocol>[WinSCP.Protocol]::Sftp</Protocol>
<HostName>insert_hostname</HostName>
<UserName>username</UserName>
<Password>mypassword</Password>
<SshHostKeyFingerPrint>fingerprint</SshHostKeyFingerPrint>
</Configuration>
From here you can use the following at the beginning of your template:
# Read XML configuration file
[xml]$config = Get-Content ".\config.xml"
param (
$localPath = $config.Configuration.localPath
$remotePath = $config.Configuration.remotePath
)
try
{
# Load WinSCP .NET assembly
Add-Type -Path "C:\Program Files (x86)\WinSCP\WinSCPnet.dll"
# Setup session options
$sessionOptions = New-Object WinSCP.SessionOptions -Property #{
Protocol = $config.Configuration.Protocol
HostName = $config.Configuration.HostName
UserName = $config.Configuration.UserName
Password = $config.Configuration.Password
SshHostKeyFingerprint = $config.Configuration.SshHostKeyFingerprint
}
I have more SFTP templates here people can use at
https://github.com/Richard-Barrett/ITDataServicesInfra/tree/master/SFTP

Change value in app.config within TeamCity

Within the Visual Studio solution that contains all our unit tests we have some text files. These text files are checked based on some results generated by our unit tests.
In order to load the files we have an app.config with:
<appSettings>
<add key="BaseTestDataPath" value="D:\MyPath\MySolution\" />
</appSettings>
Within TeamCity on each build run I want to:
Change the BaseTestsDataPath to the specific work path of the agent eg.
C:\TeamCity\buildAgent\work\1ca1a73fe3dadf57\MySolution\
I know the physical layout within the agent work folder so what I need to know is:
How to change the app.config file prior to the Nunit run against the solution in my build steps for TeamCity
There are a couple of approaches to this.
Just choose one of the following scripts, add it to your source control and setup a PowerShell build runner in your build configuration to run the script passing in the required parameters, before you run the NUnit step. If you choose option two then you'll also need to consider the transform dll.
AppSettingReplace.ps1
If you only want to change a single value you can achieve this with some simple PowerShell that will load up the config file into an xml document, iterate the app settings and change the one that matches.
# -----------------------------------------------
# Config Transform
# -----------------------------------------------
#
# Ver Who When What
# 1.0 Evolve Software Ltd 13-05-16 Initial Version
# Script Input Parameters
param (
[ValidateNotNullOrEmpty()]
[string] $ConfigurationFile = $(throw "-ConfigurationFile is mandatory, please provide a value."),
[ValidateNotNullOrEmpty()]
[string] $ApplicationSetting = $(throw "-ApplicationSetting is mandatory, please provide a value."),
[ValidateNotNullOrEmpty()]
[string] $ApplicationSettingValue = $(throw "-ApplicationSettingValue is mandatory, please provide a value.")
)
function Main()
{
$CurrentScriptVersion = "1.0"
Write-Host "================== Config Transform - Version"$CurrentScriptVersion": START =================="
# Log input variables passed in
Log-Variables
Write-Host
try {
$xml = [xml](get-content($ConfigurationFile))
$conf = $xml.configuration
$conf.appSettings.add | foreach { if ($_.key -eq $ApplicationSetting) { $_.value = $ApplicationSettingValue } }
$xml.Save($ConfigurationFile)
}
catch [System.Exception] {
Write-Output $_
Exit 1
}
Write-Host "================== Config Transform - Version"$CurrentScriptVersion": END =================="
}
function Log-Variables
{
Write-Host "ConfigurationFile: " $ConfigurationFile
Write-Host "ApplicationSetting: " $ApplicationSetting
Write-Host "ApplicationSettingValue: " $ApplicationSettingValue
Write-Host "Computername:" (gc env:computername)
}
Main
Usage
AppSettingReplace.ps1 "D:\MyPath\app.config" "BaseTestDataPath" "%teamcity.build.workingDir%"
XdtConfigTransform.ps1
The alternative approach to this is to provide full config transformation support using XDT - This does require Microsoft.Web.XmlTransform.dll to end up on the server somehow (which I normally put into source control).
The following script will transform one config file with another one.
# -----------------------------------------------
# Xdt Config Transform
# -----------------------------------------------
#
# Ver Who When What
# 1.0 Evolve Software Ltd 14-05-16 Initial Version
# Script Input Parameters
param (
[ValidateNotNullOrEmpty()]
[string] $ConfigurationFile = $(throw "-ConfigurationFile is mandatory, please provide a value."),
[ValidateNotNullOrEmpty()]
[string] $TransformFile = $(throw "-TransformFile is mandatory, please provide a value."),
[ValidateNotNullOrEmpty()]
[string] $LibraryPath = $(throw "-LibraryPath is mandatory, please provide a value.")
)
function Main()
{
$CurrentScriptVersion = "1.0"
Write-Host "================== Xdt Config Transform - Version"$CurrentScriptVersion": START =================="
# Log input variables passed in
Log-Variables
Write-Host
if (!$ConfigurationFile -or !(Test-Path -path $ConfigurationFile -PathType Leaf)) {
throw "File not found. $ConfigurationFile";
Exit 1
}
if (!$TransformFile -or !(Test-Path -path $TransformFile -PathType Leaf)) {
throw "File not found. $TransformFile";
Exit 1
}
try {
Add-Type -LiteralPath "$LibraryPath\Microsoft.Web.XmlTransform.dll"
$xml = New-Object Microsoft.Web.XmlTransform.XmlTransformableDocument;
$xml.PreserveWhitespace = $true
$xml.Load($ConfigurationFile);
$xmlTransform = New-Object Microsoft.Web.XmlTransform.XmlTransformation($TransformFile);
if ($xmlTransform.Apply($xml) -eq $false)
{
throw "Transformation failed."
}
$xml.Save($ConfigurationFile)
}
catch [System.Exception] {
Write-Output $_
Exit 1
}
Write-Host "================== Xdt Config Transform - Version"$CurrentScriptVersion": END =================="
}
function Log-Variables
{
Write-Host "ConfigurationFile: " $ConfigurationFile
Write-Host "TransformFile: " $TransformFile
Write-Host "LibraryPath: " $LibraryPath
Write-Host "Computername:" (gc env:computername)
}
Main
Usage
XdtConfigTransform.ps1 "D:\MyPath\app.config" "D:\MyPath\app.transform.config" "%teamcity.build.workingDir%\Library"
Note: The last parameter is the path to the directory that contains Microsoft.Web.XmlTransform.dll
Github Repository - teamcity-config-transform
Hope this helps
You can use File Content Replacer build feature to performe regular expression replacements in text files before a build. After the build, it restores the file content to the original state.
Optionally you can use nuget package id="SlowCheetah". That adds transformation for app.config.
On build it transforms so no need for extra scripts or dlls.

Dismiss a Powershell form controlled by a start-job task

I've been tasked with building a powershell script with a GUI which enables users to install network printers. I've succesfully managed to do so, but I cannot meet the requirement that the user be shown a 'please wait' window whilst the printers install. If I switch to the window from the main thread, the GUI hangs. If I move showing the window to a seperate job, I'm never able to close the window again. Here's my attempt:
$waitForm = New-Object 'System.Windows.Forms.Form'
$CloseButton_Click={
# open "please wait form"
Start-Job -Name waitJob -ScriptBlock $callWork -ArgumentList $waitForm
#perform long-running (duration unknown) task of adding several network printers here
$max = 5
foreach ($i in $(1..$max)){
sleep 1 # lock up the thread for a second at a time
}
# close the wait form - doesn't work. neither does remove-job
$waitForm.Close()
Remove-Job -Name waitJob -Force
}
$callWork ={
param $waitForm
[void][reflection.assembly]::Load("System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089")
$waitForm = New-Object 'System.Windows.Forms.Form'
$labelInstallingPrintersPl = New-Object 'System.Windows.Forms.Label'
$waitForm.Controls.Add($labelInstallingPrintersPl)
$waitForm.ClientSize = '502, 103'
$labelInstallingPrintersPl.Location = '25, 28'
$labelInstallingPrintersPl.Text = "Installing printers - please wait..."
$waitForm.ShowDialog($this)
}
Does anyone know how I can dismiss the $waitForm window when the long-running task has concluded?
You could try to run the Windows Forms dialog on the main thread and do the actual work in a background job:
Add-Type -Assembly System.Windows.Forms
$waitForm = New-Object 'System.Windows.Forms.Form'
$labelInstallingPrintersPl = New-Object 'System.Windows.Forms.Label'
$waitForm.Controls.Add($labelInstallingPrintersPl)
$waitForm.ClientSize = '502, 103'
$labelInstallingPrintersPl.Location = '25, 28'
$labelInstallingPrintersPl.Text = "Installing printers - please wait..."
$waitForm.ShowDialog($this)
Start-Job -ScriptBlock $addPrinters | Wait-Job
$waitForm.Close()
$addPrinters = {
$max = 5
foreach ($i in $(1..$max)) {
sleep 1 # lock up the thread for a second at a time
}
}
This first answer was correct, create the form on the main thread and perform the long running task on a separate thread. The reason it doesn't execute the main code until after the form is dismissed is because you're using the 'ShowDialog' method of the form, this method haults subsequent code execution until the form is closed.
Instead use the 'show' method, code execution will continue, you should probably include some event handlers to dispose of the form
Add-Type -Assembly System.Windows.Forms
$waitForm = New-Object 'System.Windows.Forms.Form'
$labelInstallingPrintersPl = New-Object 'System.Windows.Forms.Label'
$waitForm.Controls.Add($labelInstallingPrintersPl)
$waitForm.ClientSize = '502, 103'
$labelInstallingPrintersPl.Location = '25, 28'
$labelInstallingPrintersPl.Text = "Installing printers - please wait..."
$waitForm.Add_FormClosed({
$labelInstallingPrintersPl.Dispose()
$waitForm.Dispose()
})
$waitForm.Show($this)
Start-Job -ScriptBlock $addPrinters | Wait-Job
$waitForm.Close()
$addPrinters = {
$max = 5
foreach ($i in $(1..$max)) {
sleep 1 # lock up the thread for a second at a time
}
}
How about adding a Windows.Forms.Progressbar to the main GUI window? Update its value step by step when adding printers, so users will see that the application is working.

Resources