Kelly Garcia
asked on
add if statement powershell
Hi All,
I have this powershell script:
if the new-moverequest is successful I want to add this line code:
Get-MailboxDatabase -Status | Select-Object AdminDisplayName,DatabaseS ize,Availa bleNewMail boxSpace, Server, edbfilepath -OutVariable AvailablespaceDB
$global:AVS = [int]$AvailablespaceDB.Ava ilableNewM ailboxSpac e.split(" ")[0]
how do I add the if statement?
I have this powershell script:
try {
$OutputBox.Text += New-MoveRequest -Identity $m[$d] -TargetDatabase $TargetDatabase -WhatIf *>&1
$OutputBox.Text += "`r`n"
}
if the new-moverequest is successful I want to add this line code:
Get-MailboxDatabase -Status | Select-Object AdminDisplayName,DatabaseS
$global:AVS = [int]$AvailablespaceDB.Ava
how do I add the if statement?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Where are you launching the new-moverequest? You're just populating the outputbox.text property above, AND you're doing so with a whatif parameter...
At some point, you would need to use Get-MoveRequest against the identity and determine if the status is 'Completed'.
That is the point where you could run your additional code.
At some point, you would need to use Get-MoveRequest against the identity and determine if the status is 'Completed'.
That is the point where you could run your additional code.
ASKER
sirbounty fantastic point, how do I do this?
First question would be 'why' are you populating that property?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
GUI application for a helpdesk (multi-thread epic).
The migration process is a very difficult thing to tie a GUI to because of its completely asynchronous nature. You almost want it split in two, one part that says "yeah, queued" and another background thing (elsewhere) that fires a message (mail / slack / lync / whatever) when the task is complete.
Failing that it would either need a timer-based periodic check or an event hook. That introduces the wonderful problem of needing background threads and event triggers to affect change in the GUI (running in the UI thread). An arbitrary timer in the foreground would just lock the UI thread which makes for a particularly bad user experience.
The migration process is a very difficult thing to tie a GUI to because of its completely asynchronous nature. You almost want it split in two, one part that says "yeah, queued" and another background thing (elsewhere) that fires a message (mail / slack / lync / whatever) when the task is complete.
Failing that it would either need a timer-based periodic check or an event hook. That introduces the wonderful problem of needing background threads and event triggers to affect change in the GUI (running in the UI thread). An arbitrary timer in the foreground would just lock the UI thread which makes for a particularly bad user experience.
Thanks Chris - that makes more sense, and as I suspected.
If this is an interface, I'd present an option to the user to check all currently queued move requests, or filter based on complete vs failed, etc. Then you could easily report back the status of one or multiple requests using a get-moverequest, or get-moverequestStatistics depending on what you want to display for results.
If this is an interface, I'd present an option to the user to check all currently queued move requests, or filter based on complete vs failed, etc. Then you could easily report back the status of one or multiple requests using a get-moverequest, or get-moverequestStatistics depending on what you want to display for results.
For example, if the MoveRequest object had a property called Status which clearly said Success we could do this (which is moderately disgusting :)).
Open in new window