Meet the third PowerShell (Part II)

We continue to feel the third PowerShell with our insatiable fingers. Last time we did a review of the innovations and touched on several additions: we tried the Show-Command cmdlet, ran automatic module loading, looked at the simplified language syntax and configured the session file, partly delegating the session privileges to the user.

Scheduled jobs

PowerShell tasks are, in essence, the same Windows tasks, they can also be executed according to a schedule, they can also be launched when a particular trigger is triggered, they can also be stopped or interrupted, like all other tasks, only with the difference that they are created from PowerShell and are specially designed for running PowerShell scripts.
Let's first create our task, let it be expressed, for example, in the execution of the following script:

 (Get-Date).ToString() + " -  " | 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() + " -  " | Out-File "C:\logfile.txt" -Append 

If it is not very clear, then the block inside is not quite the classic sieve of Eratosthenes: the script finds prime numbers in the range 3..100. We carefully save the script text to the file C:\ScheduledJob.ps1 .
And now we create our scheduled task:

 $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 Task Scheduler Library/Microsoft/Windows/Powershell/ScheduledJobs branch:
')


Now we are waiting for the offensive 16:39 and voila, the lines appeared in our logfile.txt :
24.06.2012 16:39:03 -
24.06.2012 16:39:04 -
And now the most interesting thing - what is this all about? After all, the task could be entered as follows: even though the script, although not the script, at least anything. But remember that our PowerShell program showed us simple numbers? Launch another PowerShell window and execute:

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

We get such a picture:



The task was completed, some result was obtained, this result was successfully saved in the PowerShell bins, and now we simply extract this result from these bins for our own purposes, and between the execution and the extraction we can reboot, we can perform other tasks, the result will not disappear . This is actually a nice thing, because you can track the performance of your tasks, including mistakes: for example, I can replace the Eratosthenes sieve with the string 1/0 and after the Receive-Job I will see Attempted to divide by zero , written in red, which can not please the eye. Well, to put a point, I’ll share the address where the PowerShell bins I’ve named are located: %userprofile%\AppData\Local\Microsoft\Windows\PowerShell\ScheduledJobs , there is a set of folders, xml files and identifiers with input and output parameters.

Robust sessions

The idea, as I understand it, is taken from Remote Desktop Services: the established remote session is saved for a while when the connection is broken, and even if something happens, it can be restored from another machine. Let's see how this is done, at w2012cl1 execute:

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

Thus, we will enter the session and assign a variable $x value abcdef123 , we will use this variable to check whether this session is or not, whether the session data is lost or not.
Now in the settings of the network interface card of the virtual machine we do “oh!”:



And for four minutes, PowerShell tries to reconnect:



We return the connection in the map settings, and the PowerShell session is restored:



And that's not all tricks, now we will intercept the session created on one machine from another machine. At w2012cl1 perform the actions:

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

I draw your attention to the fact that the session went into the Disconnected state, we can now join it from another machine, w2012dc1 (yes, here I understand, the experiment is not too clean, since the session is on the same machine, but we will use the commands as if it was deleted):

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

And we get the variable stored in the session on another machine. Notice the Invoke-Command cmdlet, I used it to simply send a script block inside the session, but theoretically I could log into the session using Enter-PSSession and assign the variable to the value inside the session exactly as in the first example.

I wanted to fit everything into two parts, but the next topic of PowerShell innovations, “Workflows” or “workflows”, is quite voluminous by itself, so I will describe it separately in the third part, along with the new PowerShell ISE updates. Well, as a bonus, in this case I will add something that was not announced in advance, namely access to PowerShell via the Web: I will show you how to type commands directly in the browser.