Transcript Installing the PowerShell Module

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
3
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
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
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
5
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

–
To determine if the profile exists (returns True if file exists)

–
PS C:\> New-Item –path $profile –itemtype file –force
To edit the profile

–
PS C:\> test-path $profile
To create a new profile if one does not exist

–
PS C:\> $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
6
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
8
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
9
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-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.
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.
– 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”} | ….
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