Getting Started with the Data ONTAP PowerShell Toolkit

1. Getting Started with theData 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 NetAppManageONTAP SDK. • Free! (NOW login required for download) • Posted to the communities website. • 528 cmdlets in version 1.5.0. • 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 2008 (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. 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 3.5.1 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. Basicusageexamples

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 SnapShotschedules

16. Set SnapShot reserve

17. Manipulate CIFS shares

18. Monitor performance

19. Moreadvancedexamples

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. Additionalnotes

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-ExecutionPolicyRemoteSigned • 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!