How to Check Data ONTAP 8.3.2 Upgrade Requirements Using a PowerShell Script

by Frequent Contributor ‎2015-06-03 01:10 PM - edited ‎2017-04-12 02:42 PM


This script checks a specified cluster for the items in the "Steps for preparing for a major upgrade" section. The items that are covered are the ones that can be addressed prior to the actual software image update. These are outlined roughly on pages 31-54 in the guide. Based upon the output of the script you can make the necessary adjustments in the cluster to ensure a successful upgrade.


Step 1: Configure PowerShell Environment

  • .NET Framework 4.5 or greater installed which is available here.
  • PowerShell 4.0 or later installed (must be installed after .NET Framework 4.5 or later is installed) which is available here
  • NetApp PowerShell Toolkit 3.2.1 installed which is available for download here

Step 2: Download and Prepare to Run Script

  • Save the attached file with a ".ps1" extension.  Current version 2.5 was uploaded on April 12, 2017.
  • Start Windows PowerShell with the "Run as Administrator" option.
  • Execution policy set appropriately to run scripts within PowerShell (currently this script is unsigned).
  • More help on these requirements can be found here.

Step 3: Run Script (See Details Below)

  • Find more information about the script by issuing the following in PowerShell:
    get-help .\83UpgradeCheck.ps1 -full
  • Syntax:
    .\83UpgradeCheck.ps1 [-HyperV] [-FCP] [-ISCSI] [-NoHyperV] [-NoFCP] [-NoISCSI]
    [[-Cluster] <String>] [[-Username] <String>] [[-Password] <String>] [[-RunSection] <String[]>] [[-SkipSection] <String[]>] [[-Outpu
    tFile] <String>] [-PostCheck] [-ShowVersion] [<CommonParameters>]
  • Here is a brief explanation of the optional parameters, see above get-help output for more detail:
    HyperV: Cluster has Hyper-V over SMB in use
    FCP:  Cluster has FCP in use
    ISCSI:  Cluster has ISCSI in use
    NoHyperV: Cluster does not have Hyper-V over SMB in use
    NoFCP:  Cluster does not have FCP in use
    NoISCSI:  Cluster does not have ISCSI in use
    Cluster: Specify the cluster management LIF used for connection
    Username:  Specify the username to connect to the cluster
    Password:  Password to connect to the cluster (note - this is in clear text)
    RunSection:  One or more specific sections of the script to run
    SkipSection:  One or more specific sections of the script to skip
    OutputFile:  A file name to write the output of the script results
    PostCheck:  To run after 8.3.2 upgrade checks
    ShowVersion:  Show the version of the script
  • The script output is color coded as follows:
    Purple - Section headers, tells you what is being checked
    Red - The check failed
    Green - The check succeeded
    Yellow - User interaction is needed
    Blue - At the completion of the script shows count of errors and warnings


  1.  Clustered Data ONTAP 8.3.2 Upgrade outlined in several major sections can be found here.

New Contributor

Too many Domain Controllers - script is hanging.

Client has a scenario where there are many, many Domain Controllers/Name Servers and on top of that they have many SVM's. The script is hanging for long periods of time checking the DC's/Name-servers for each SVM. I suspect there may be some stale entries in the Discovered DC list but should it take 8-10 minutes for section/step 29 alone? Here is the comment from the client:


This script is hanging on Name Server query.  BAC has a flat network and the script is hanging because it’s trying to query 13k name servers.  Do we need query all name servers?  Can we adjust the script so that once we successfully connect to a name server, the script moves on?


So the question is: Is there a way to minimize the number of DC's/Name-servers that get queried while the 83upgradecheck script is running?



Mike Smith

Frequent Contributor

mikesmit - thanks for the feedback.  There is an issue that the update could fail on the check when there is a large number of CIFS domain servers discovered.  It is awaiting a public report here:


In reference to the script it mimics the same activity that the update itself goes through.  I'm going to make an update to the script to put some more output in this section as to where it is in the queries of name service servers so you can see which particular one is taking a long time to query.

Frequent Contributor

Update 2.5 of the script coming, pending publish of this page.  Updates from suggestions in these comments:


  • Increased buffer size for the PowerShell window to have more data able to be captured in HTML and RTF output.
  • Removed infnite volume check for systems already on 8.3.
  • Added output showing quantity of each name service servers that were queried.
  • Fixied the summary portion of the SAN section to more accurately reflect what was captured in the main portion of that section.
New Contributor

Thanks mcgue! Specifically I think the client is in need of a way to bypass or modify the number of DCs/Nameservers queriec while the script is running. Would it be possible to provide a list of "known good DCs/nameservers" to the script in order to expedite the upgrade check script completion?


Thank you for a terrific script. We used this script exhaustively across the current client I support globally. Very helpful.



Mike Smith

PSC - resident


Hi McGue,



This script is very useful, Thanks!



while running this script, I'm getting this Error Message.


Section 41) Checking to ensure the system file /var/INTERNCONFVERS reflects the currently installed version            
***** Error Found *****                                                                                                
The value in /var/INTERNCONFVERS is either missing or invalid.  Full contents of the /var/INTERNCONFVERS is below.     
Error: command failed: SSH keys missing on the local node: use the "debug                                              
       system regenerate-systemshell-key-pair" (privilege diag) command to                                             
       regenerate the keys.                                                                                             
***** Error Found *****                                                                                                 
The value in /var/INTERNCONFVERS is either missing or invalid.  Full contents of the /var/INTERNCONFVERS is below.     
Error: command failed: SSH keys missing on the local node: use the "debug                                               
       system regenerate-systemshell-key-pair" (privilege diag) command to                                             
       regenerate the keys.                                                                                             


Frequent Contributor



It looks like you are facing the issue described here:


There is a procedure to correct on the cluster; however, it requires involvement of technical support.  I would suggest opening a new support case to get proper guidance on the procedure.



Thanks again for this excellent tool! We are now using it primarily for ONTAP 9.x upgrade planning, and we are making heavy use of the SAN section. We're even considering running the script regularly (not just for upgrades) to check for initiators not connected to all nodes in a given cluster (iscsi).


Is there a way to distill the detailed SAN output ($SANDisplayFullOutput) to only include the LUNs with errors? The detailed output in that section is fantastic, but it's daunting to scroll through all of the results when it includes the healthy ones. Is there any easy way to display only those LUNs/igroups that need attention?


For this purpose, we don't need to see the mapped LUNs with no active initiators (warnings) or "correct" configs (no errors/warnings) -- I only really want to see the LUNs where an initiator is only logged in to one node or where initiators are not logged in to all nodes in the cluster (errors).


I've tried using the following command to pull out the details when an error is encountered, but because the output has inconsistent carriage returns and other errors stuck in the middle of the output, it's still pretty messy:


cat results.txt | grep -B 20 "Not logged in on all nodes or ports" >> results_filtered.txt


The "Not logged in on all nodes or ports" message seems to always come at the end of the output for a specific lun, so I chose to pull out 20 lines above that string to try to capture all the important details, but in some cases, the "All access to this LUN is via proxy paths" or "Currently logged in only on a single node and will be unavailable during a takeover" error messages are stuck in the middle of the LUN details, so it makes the 20 lines not always work. Obviously different cluster sizes will also impact this output (more nodes = more lines), so I'm hoping to find something that works reasonably well for most scenarios.


Is there a quick and dirty way to do this using the script, or is it just time I learned PowerShell? Smiley Very Happy


Thanks again!

New Contributor

Hi Tim, i'm in a situation where the SVM mgmt LIF can't reach external services, but the data LIF can.  Your script is coded such that if it finds a SVM mgmt LIF attempts to contact external services, and regardless of the results doesn't try the same connection test with the data LIF.  Question is, will the upgrade fail if this is not remediated?  In other words, will ONTAP try the data LIF after the mgmt LIF failed to contact external services? 



The management LIF has a wide open firewall (used for CIFS style backup) but resides on a different VLAN.  This is a hosting company the network is very segmented.


I'd rather not go through the hassle of remediating this particular problem if it's not necessary. 


Thanks in advance.



This NetApp Community is public and open website that is indexed by search engines such as Google. Participation in the NetApp Community is voluntary. All content posted on the NetApp Community is publicly viewable and available. This includes the rich text editor which is not encrypted for https.

In accordance to our Code of Conduct and Community Terms of Use DO NOT post or attach the following:

  • Software files (compressed or uncompressed)
  • Files that require an End User License Agreement (EULA)
  • Confidential information
  • Personal data you do not want publicly available
  • Another’s personally identifiable information
  • Copyrighted materials without the permission of the copyright owner

Files and content that do not abide by the Community Terms of Use or Code of Conduct will be removed. Continued non-compliance may result in NetApp Community account restrictions or termination.