Getting Started

with the
Data ONTAP
PowerShell Toolkit
Leverage Microsoft PowerShell
for (almost) all your Data ONTAP
management needs

Slides courtesy of Jason Cole

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 1.5.0.
Near 100% coverage for Data ONTAP API
set.
Some host-side, storage-centric cmdlets.
2

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

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; its simplest to allow it to install to just one of those (the
system location so its 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
4

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
files 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

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

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

Basic
usage
examples

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

Gather basic info from the controller

10

Gather the list of volumes

11

Get more volume information

12

Volume SnapShot and SnapReserve Info

13

Add and remove licenses

14

Set SnapShot schedules

15

Set SnapShot reserve

16

Manipulate CIFS shares

17

Monitor performance

18

More
advanced
examples

19

Perform command on multiple controllers

20

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!

21

Additional
notes

22

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-Na VolRoot).Name} | Get-

NaSnapShotReserve

In many cases, positional parameters are supported, so you dont

have to type the parameter name (such as Name). Review the GetHelp 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.

23

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) { ConnectNaController -Name $filer | .. }

Even better would be to populate the hostnames into

an XML structure that could be organized by site.

Im 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} | .
24

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)
25

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

26

27