We meet the third PowerShell (part II)

we Continue to feel our insatiable fingers third PowerShell. last time we have made an overview of the innovations and touched a few additions: I tried the cmdlet Show-Command, run the automatic loading of modules that looked at a simplified language syntax and configures the session file, simultaneously podlekareva the user session of the authority.

Scheduled jobs

PowerShell job is essentially the same task in Windows, they just can run on schedule, exactly the same can be triggered by actuation of a trigger, they are just as likely to be stopped or interrupted, as with all other jobs, only with the difference that they are created from PowerShell, and specially designed for executing PowerShell scripts.
Let's start our task, though it is expressed, for example, in the following script:

the

(Get-Date).ToString () + "starts execution" | Out-File "C:\logfile.txt" -Append
for ($i = 3; $i -lt 100; $i++)
{
$flag = $true
for ($j = 2; $j-lt $i; $j++)
{
if ($i % $j -eq 0) {$flag = $false}
}
if ($flag) {$i}
}
(Get-Date).ToString() + "- end" | Out-File "C:\logfile.txt" -Append

If you are not very clear, the unit inside is not quite the classic sieve of Eratosthenes: this script finds primes in the range 3..100. The text of the script we carefully store it in a file C:\ScheduledJob.ps1.
Now create our scheduled task:

the

$trigger = New-JobTrigger -Once -at 16:39
$job = Register-ScheduledJob -Name Job-FilePath "C:\ScheduledJob.ps1" -Trigger $trigger

The task appears in the scheduler in the thread Task Scheduler Library/Microsoft/Windows/Powershell/ScheduledJobs:



Now waiting for the onset of 16:39 and voila, in our logfile.txt has the line:
24.06.2012 16:39:03 - the beginning of the execution
24.06.2012 16:39:04 - the end run
And now the most interesting — what is this all intended? Because schedulet task could be so: though the script, though not the script, anything you like. But remember that our PowerShell program we output a Prime number? Run another PowerShell window and execute:

the

Import-Module PSScheduledJob
Get-Job
Receive-Job -Name of Job

We get such a picture here:



The task was completed, obtained certain result, this result was successfully stored in the bins PowerShell, and now we have this result of these simple bins are extracted for their own purposes, and in the interval between the execution and the extraction can reboot, you can perform other tasks, the result will not disappear. It's actually a nice thing, because you can track the performance of its task, including errors: for example, I can replace the sieve of Eratosthenes string 1/0 and after Receive-Job see Attempted to divide by zero, written in red font which is not pleasing to the eye. Well, to make a point, I will share the address where these bins PowerShell: %userprofile%\AppData\Local\Microsoft\Windows\PowerShell\ScheduledJobs, there is a set of folders, xml files and identifiers input and output parameters.

Robust sessions

The idea, as I understand it, taken from Remote Desktop Services: set remote session will persist for some time when you break ties, and even, in which case, you can restore it from another machine. Let's see how it is done with the w2012cl1 perform:

the

New-PSSession -ComputerName w2012dc1 -Name RobustSession
Enter-PSSession -Name RobustSession
$x="abcdef123"

Thus, we enter into the session and assign there some variable $x to abcdef123, this variable we will use to check whether it's session or not, is lost if session data or not.
Now in the settings of the network card of the virtual machine doing the "oops!":



And PowerShell for over four minutes trying to reconnect:


Return the connection in the settings of the card, and the PowerShell session is restored:



And that's not all the tricks, now we can see the session created on one machine, from another machine. On w2012cl1 activity:

the

$icptsess = New-PSSession -ComputerName w2012dc1 -Name InterceptedSession
Invoke-Command -Session $icptsess -ScriptBlock {$x="abcdef123"} #Send command to the session
Disconnect-PSSession -Name InterceptedSession

Draw your attention to the fact that the session moved into the Disconnected state, can now join it from another machine, w2012dc1 (Yes, I realize the experiment is not too clean, as the session on the same machine, but we will use commands as if it was removed):

the

$icptsess = Connect-PSSession -ComputerName w2012dc1 -Name InterceptedSession
Invoke-Command -Session $icptsess -ScriptBlock {$x}

And we get saved inside a session variable on a different machine. Please note the cmdlet Invoke-Command, I used to simply send session inside a script block, but theoretically could enter the session using Enter-PSSession to assign a value to a variable inside the session exactly as in the first example.

I wanted to fit it all in two parts, but following the theme of innovation PowerShell "Workflows" or workflows, it turns out enough volume by itself, so I'll describe separately in the third part, together with the new PowerShell ISE. And as a bonus, in this case, add something that was not announced in advance, namely access PowerShell via Web will show you how comanducci dial directly in the browser.

Article based on information from habrahabr.ru