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
