1. Getting Started with the Data ONTAP PowerShell Toolkit
Leverage Microsoft PowerShell for (almost) all your Data ONTAP management needs
Slides courtesy of Jason Cole

2. Data ONTAP PowerShell Toolkit
Maintained by the NetApp Management Framework Integration Team.
Provides a PowerShell wrapper around the NetApp ManageONTAP SDK.
Free! (NOW login required for download)
Posted to the communities website.
528 cmdlets in version
Near 100% coverage for Data ONTAP API set.
Some host-side, storage-centric cmdlets.

3. What do you need to get started?
Windows Management Framework
WinRM 2.0 (Windows Remote Management)
Powershell 2.0
Already installed on Windows Server 2008 R2 and Windows 7
Can be installed on Windows Server (SP1), Server 2003 (SP2), Vista (SP1 and SP2) and XP (SP3)
Data ONTAP PowerShell Toolkit

4. Installing the PowerShell Module
Unzip the Data ONTAP PowerShell toolkit to a folder under one of these locations
User specific location (only available to the currently logged on user)
%USERPROFILE%\Documents\WindowsPowerShell\Modules\
System location (available to all users)
%SYSTEMROOT%\system32\WindowsPowerShell\v1.0\Modules\
Or use the provided Install.ps1 script, which will unzip and copy the files. The script will offer to copy to each location in %PSModulePath% in turn; it’s simplest to allow it to install to just one of those (the system location so it’s available to all users).
Open the Windows PowerShell and verify the module exists
PS C:\> Get-Module –listavailable
Import the module
PS C:\> Import-Module DataONTAP

5. NetApp Confidential - Internal Use Only
Installation gotchas
If you prefer to add the module by unzipping the DataONTAP.zip file manually, you may need to clear the security attribute first in the file’s Properties window.
On some versions of Windows, you may need to add the feature “.NET Framework Features”.
NetApp Confidential - Internal Use Only

6. Setting up your PowerShell profile
This is an optional step
PowerShell profiles are used to add aliases, functions and variables to each session
There are 4 locations that you can save a profile to and the below steps describe the creation of a user specific profile
To display the path to the profile
PS C:\> $profile
To determine if the profile exists (returns True if file exists)
PS C:\> test-path $profile
To create a new profile if one does not exist
PS C:\> New-Item –path $profile –itemtype file –force
To edit the profile
PS C:\> notepad $profile
Add this line into the profile to load the DataONTAP module each time the shell is opened
PS C:\> Import-Module DataONTAP

7. How to find help To view the list of cmdlets available to you
PS C:\> Get-NaHelp
Use -Category switch and/or wildcards to narrow the results.
To view the full HTML help
PS C:\> Show-NaHelp
To see cmdlet specific help
PS C:\> Get-Help Get-NaVol
More detailed help can be displayed
PS C:\> Get-Help Get-NaVol –Full
Every cmdlet has at least one real usage example in its online help.

8. Basic usage examples

9. You must first connect to a controller
The coolest part about this is that unless you specify credentials it will attempt to authenticate with your current credentials.
Uses RPC to connect to the controllers (by default)
Also supports HTTP/HTTPS connections

10. Gather basic info from the controller

11. Gather the list of volumes

12. Get more volume information

13. Volume SnapShot and SnapReserve Info

14. Add and remove licenses

15. Set SnapShot schedules

16. Set SnapShot reserve

17. Manipulate CIFS shares

18. Monitor performance

19. More advanced examples

20. Perform command on multiple controllers

21. Get the SnapShot Delta for all volumes on all controllers (this is for you Capt. Kirk!)
Would I actually do it this way? Absolutely not! But it works!

22. Additional notes

23. Miscellaneous recommendations
You should modify your default script security settings before you get too far. The default is highly secure (‘Restricted’).
Current setting: PS C:\> Get-ExecutionPolicy
PS C:\> Set-ExecutionPolicy RemoteSigned
Instead of calling out the root volume as “vol0” (which may not always be its name) use the Get-NaVolRoot cmdlet.
PS C:\> Get-NaVol | where {$_.Name –ne (Get-NaVolRoot).Name} | Get-NaSnapShotReserve
In many cases, positional parameters are supported, so you don’t have to type the parameter name (such as –Name). Review the Get-Help for the cmdlet to see if it is required if you want to make the command more concise.
Many cmdlets that retrieve info support wildcards, even if the underlying Data ONTAP API does not.

24. Slightly better ways to do stuff
Instead of defining each controller from the CLI ($node1 = Connect-NaController …), you could add all the hostnames into a text file and read them in.
foreach ($filer in Get-Content C:\filers.txt) { Connect- NaController -Name $filer | ….. }
Even better would be to populate the hostnames into an XML structure that could be organized by site.
I’m thinking of NMCI here, where you could then operate on a set of hostnames at a particular site only.
[xml]$s = Get-Content C:\filers.xml
$s.NMCI.Host | where {$_.Site –eq “WNYD”} | ….

25. Other ideas
Checking all the SnapMirror lag times and outputting only those over a certain threshold
Performing a disk zero spares
Configuring options to be consistent across the enterprise (NTP, WAFL, CIFS, etc)
Turning on and configuring dedupe
Scripting controller rollouts
Monitoring for performance issues
…. (See the Toolkit community for more script ideas)

26. Questions?
Post your ideas and questions on the NetApp Communities page where you got the Toolkit!