Commands:
PowerShell is powered by commands. Commands get things done. There are four basic types of commands:
- cmdlets
- functions
- scripts
- native commands.
Cmdlets (pronounced command-lets) are compiled commands that are installed and registered with PowerShell; they are all named using a verb-noun combination. To make them easy to remember, the noun part of a PowerShell cmdlet is always singular. The verb portion of the name should be one of the PowerShell acceptable verbs.
As you might have already guessed, the SharePoint commands that we will be using are cmdlets. You saw that SharePoint installed the cmdlets on the server, and the Management Shell registered them with the host using the PSC1 file; and you now know how to manually register them in the ISE. You can also create custom cmdlets, but that is a topic beyond the scope of this book. To learn more about writing your own cmdlets, see the MSDN article at http://msdn.microsoft.com/en-us/library/dd878294(VS.85).aspx.
Functions:
Functions are made up of a command or a series of commands that are intended to be reusable for performing a task multiple times within the same script. Functions can accept parameters (variables that are passed to the function at the time the function is called), which enables the same code to be executed with different parameters each time. This provides the benefit of reducing the amount of duplicate code in a script. Functions are defined in PowerShell by typing the function into the host. PowerShell then parses the function and verifies the syntax. Functions can be reused for the lifetime of the host session. If you close the host then you lose the function, and you will need to enter it again when you start another session with the host. You can enter functions into your profile so they will be available whenever you start a session.
Scripts
PowerShell scripts are made up of a mix of commands, functions, loops, decision trees, user input/output — basically all the methods available to PowerShell for creating reusable code with program like functionality. General SharePoint administration will commonly result in the use of “oneliners,” whereas scripts are generally reserved for larger-scale repetitive tasks, such as an automated installer for SharePoint. Aside from the amount of code involved, a primary difference between a "script" and a "one-liner" is that scripts are saved to a text file with a .PS1 file extension. Later you can run the script by typing in the filename.
Another great benefit of the script is that once a script is created and tested, it can be saved to a script library and reused. By default, hosts do not run unsigned scripts. This is to protect you from accidentally running scripts that have the same name as common commands. In addition, hosts will warn you if you attempt to run a script that has not been signed. This prevents you from executing a script that has been modified to do something malicious. You can modify the security setting using the cmdlet Set-ExecutionPolicy. Because you can accomplish so much using the SharePoint cmdlets, Scripts are only necessary if you want to chain together a complicated series of cmdlets or walk through complicated loops.
Native Commands
Native commands are commands that run outside of the host process, such as "notepad.exe" or "stsadm.exe". These commands can still be called from within the commands or scripts that you can execute in the PowerShell host. This provides useful functionality that may not be provided by PowerShell directly. For example, suppose your script were logging information to a .txt file, and at the end of the execution you wanted to display that .txt file automatically. You could add a line such as the following to the end of your script to automatically launch Notepad.exe in its own process and display your log file:
Notepad.exe "MyLog.txt"
Listing the SharePoint Commands
The toughest part of using a command-line interface, whether it’s PowerShell, the old Windows CMD prompt, or a Linux bash shell, is determining which commands you can use. PowerShell provides the Get-Command cmdlet to retrieve a list of available commands. Used in isolation, the Get-Command cmdlet will return all commands that are known to the host. Get-Command, like many commands, accepts optional parameters. Because we are interested in only the SharePoint 2013 commands, we can limit the commands displayed to just the SharePoint 2013 commands by using the optional -Module parameter. To list only SharePoint commands, execute the
following command:
Get-Command -Module Microsoft.SharePoint.PowerShell
Below Figure displays the output of the Get-Command cmdlet using the –Module parameter.
We mentioned earlier that all PowerShell cmdlets consist of a verb and a noun. All the nouns in the SharePoint PowerShell cmdlets start with “SP.” The Get-Command cmdlet accepts wildcards, which you can use to get a list of all the SharePoint PowerShell cmdlets in an easier-to-remember method:
Get-Command -noun sp*
As the preceding example demonstrates, you can filter the list somewhat by using the optional -noun or -verb parameter for Get-Command. For example, if you were wondering what commands work with a web application, use the following command:
Get-Command –Module Microsoft.SharePoint.PowerShell –noun SPWebApp*
Because the SharePoint module is the only module with cmdlets using the SPWebApplication noun,
Command to use for backups, use the following
Get-Command –Module Microsoft.SharePoint.PowerShell –verb Backup

No comments:
Post a Comment