Take Control with Powershell
PowerShell provides plenty of sorting and filtering options, then, but it's not simply a passive reporting tool. Take a look at this:Get-Service | Out-GridView -Title 'Select in order to restart! ' -OutputMode Single | Restart-Service -WhatIfWe're getting a placed of installed services, and displaying them with a custom window title as an user prompt. The -OutputMode Single switch says PowerShell that we're permitted to select one item within the list. If we do this, and click 'OK', our chosen service is passed along the pipeline to the next cmdlet, Start-Service, which halts and starts it for us, which is very helpful as a way to try to revive any services that are behaving inappropriately.
Or, at least, it might restart the service anytime we hadn't included the -WhatIf switch, which explains to PowerShell to simply screen its action instead. This kind of is a convenient safety option, which means you can see how a cmdlet might work with no risk of, in this case, accidentally stopping a service that really should be left alone. Yet if you wish to try it for real, enter the same cmdlet with no -WhatIf, and you'll have created your personal custom service-restarting tool.
You may, of course, do something similar with processes, services, and some other objects PowerShell can manipulate. But even which not the final of the story:
Get-Service -ComputerName MyPC | Out-GridView -OutputMode Sole | Restart-Service -WhatIfCmdlets like Get-Service and Get-Process aren't restricted to any local system. Use the -ComputerName switch with the name of any network computer and you're free to see what is actually running, too (assuming your Windows user account has the privileges to get them). PowerShell may then control remote systems in exactly the same way as your own PC.
PowerShell ISE
To date we've recently been working only in the PowerShell console, entering directions one by one and seeing the results right away. There may be another way to run code, though - in the PowerShell Integrated Scripting Environment (ISE). It's a little more complex, but much better when you'd like to string several cmdlets with each other, or create some code for reuse later. Kick off it by searching for PowerShell and clicking 'Windows PowerShell ISE', entering Powershell-ISE. exe in the Manage box, or by going into ISE at the PowerShell console.The ISE clears with a two-pane user interface. On the left hand side is the console, to can enter PowerShell directions. On the right is the Commands Add-On, a helpful tool that can help you build commands with the mouse.
Type process in the Commands 'Name' box; you'll see various matching cmdlets. Select 'Get-Process' to see its details, helping you understand what the cmdlet can do. Click the 'Name' case, for instance, and you should find a Module box. What does this do? Verify it and click 'Run'. The Commands Add-On increases the cmdlet Get-Process -Module, runs it in the console, and displays the results - an established of your processes, where each one includes their loaded modules (DLLs and other support files).
When this can be helpful, the ISE console has some extra tricks to increase your PowerShell code. Begin typing a cmdlet (try Get-Process again) and ISE displays possible fits. When you've reached Get-Pro, the proper cmdlet should be highlighted, and you could press [Tab] to automatically your remaining characters.
Is actually a similar story when it comes to going into parameters. Tap the space bar, then a hyphen, and ISE lists the various Get-Process options. Employ the cursor keys to scroll down, then choose '-Module', press [Enter] and again it is automatically added to your command, no inputting required.
As you can see, there's more to learn in the ISE, but it does also make it better to explore what PowerShell has to offer. Now we just have to make use of it to build a script.
Hardware scripting
Click 'View > Show Script Pane' to expose the program pane. This can be an individual area where you can enter a string of commands, across as many lines as necessary, without having them executed immediately. Instead, you can run all the commands in the Script pane at any time by hitting [F5] or clicking 'Debug > Run'.To give this a try, your pursuing four commands in to the Program pane.
$computername = read-host "Which computer name would you like to check? "
$os = Get-WmiObject -Class Win32_OperatingSystem -ComputerName $computername
$lastbootuptime = $os. ConvertToDateTime
($os. LastBootUpTime) Write-output "$computername last boot time was $lastbootuptime"
This is a straightforward script, which tries to determine the last boot coming back whatever network computer you specify. Although very brief, it's much more advanced than our previous code, and introduces several new concepts.
The first series, for instance, uses the read-host cmdlet to screen a prompt, asking the user to enter a computer name. This is then stored in a variable called $computername.
The other line uses WMI to retrieve the operating system for the specified computer, while the third then obtains its boot time and converts it into a readable format. (Don't worry about the complex details here; all you need to remember is that Get-WmiObject can return useful information with regards to your system configuration. )
Finally, the last Write-output cmdlet sends a concept to the console. The variables will be substituted by their actual principles so, for example, you might see "MyServer previous boot the time has been the time hath been 06/10/2014 08: 30".
Press [F5] to launch the screenplay. If you possibly could access a network PC, enter its name, otherwise enter localhost or simply a period to check the local system. And that is it - your first multi-line script. Click 'File > Save As' and save it as C: \Scripts\LastBootTime. ps1 (creating the folder, if necessary), ready to be were recalled any time you like.
Our test ISE script was very small, however the principles can be used to run whatever you like. Go to the Microsoft Scripting Middle - or seek out PowerShell Scripts - to discover more examples, copy and stick them into the server scripting pane, and press [F5].
There is still one issue remaining, though: how will you run the software outside PowerShell? Double-clicking it seems an evident solution, but do that and the file opens in Notepad; less than helpful.
You could relaunch PowerShell and enter C: \Scripts\LastBootTime. ps1 at the command series, but that won't work, either. You'll just see a message complaining that "running scripts is handicapped on this system". This kind of is normal; the arrears security settings place tight limits on scripts to stop their abuse by viruses.
To get around this problem, you may need to learn more about PowerShell's execution plan. The following cmdlets will help:
Get-ExecutionPolicyThe first line implies that your policy is placed to 'restricted', blocking intrigue. If so, entering the other line sets execution plan to 'RemoteSigned', instead. This implies your own scripts will run immediately, but any scripts you download will have to be electronically signed by a relied on publisher.
Set-ExecutionPolicy RemoteSigned
Test the new policy by entering C: \Scripts\LastBootTime. ps1 again, which time your script should run. If it's too much hassle to get into the full path each time, just add C: \Scripts (or whatever directory you choose for your scripts) to your WAY environment variable (press [Win]+[X], click 'System > Advanced System Settings > Environment Variables', double-click 'Path' in 'System Variables', then add a semi-colon and the folder -; C\Scripts - to the finish of your path).
This may not quite the end of the storyplot. The official PowerShell selection has its own useful details on executing intrigue, and there's a nice trick you can use to launch scripts from a shortcut but usually you now know how to test, write and run PowerShell code. Really time now to get started some serious scripting.
Read More: Powershell Tip and Tricks
Post a Comment