In order to manage an XtremIO array through PowerShell you must install the XtremIO Windows PowerShell Module. This module works as a translator from PowerShell commands to REST calls and vice versa. REST calls are sent to the XMS to retrieve info or modify configurations. REST responses are returned to the original requesting client machine. As such, when analyzing issues from the XMS we will refer to the rest.log to determine if the REST calls are making it through and if they are encountering any errors.

Review rest log to verify valid REST calls on the XMS. For example, code 200/400 indicate success.
Run a simple  Power Shell command to verify.


If the expected result is received, the above fault message is a false positive from the Windows host.

Examples of Good Rest API Calls:
2017-05-17 17:42:40,230 - RestLogger - INFO - rest_server::log_request:98 - REST call: with args {}
2017-05-17 17:42:40,234 - RestLogger - INFO - rest_server::log_response:110 - REST response with code 200
2017-05-17 17:42:40,243 - RestLogger - INFO - rest_server::log_request:98 - REST call: with args {}

FAULT OBSERVED via Power Shell;

Could not retrieve XMS data from XMS Server, or XMS is less then 4.0.0.
At C:\windows\system32\windowspowershell\v1.0\Modules\XtremLib\xtremlib.psm1:6426 char:9
+         throw "Could not retrieve XMS data from XMS Server, or XMS is ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Could not retri...ess then 4.0.0.:String) [], RuntimeException
    + FullyQualifiedErrorId : Could not retrieve XMS data from XMS Server, or XMS is less then 4.0.0.

--Scenario 1
False positive observed on  Windows 10 and  XMS version(s) 4.2.1-build 6, 4.2.1 build 7, and 4.2.1 build 8.

--Scenario 2
Verify that the  XMS object name hasn't been modified;

xmcli (tech)> show-xms
Name       Index SW-Version Xms-IP-Addr  Xms-IP-Addr-Subnet Xms-Mgmt-Ifc REST-API-Protocol-Version IP-Version Default-User-Inactivity-Timeout Repeating-Alert-Threshold
XYZIO0008 1     4.2.1-8    172.20.xx.yy 255.255.255.0      eth0         2.1                       ipv4       10                              10

--Scenario 3
Another reason for the "Could not retrieve XMS data from XMS Server, or XMS is less then 4.0.0" error message is due to the weak ciphers script having previously been run on the XMS (see https://dell.to/3zGlGHU ).  This script blocks the default PowerShell connectivity to the XMS via TLS 1.0.  If the customer has already imported the certificates, and installed the XIO PowerShell module libs, but running the commands from the Resolution section below only returns the error message, and still does not show the output for the command, then have the customer try the following commands from their PowerShell:

See Scenario 3 in Resolution section below
See Notes below for more information on TLS connectivity

Please contact Dell EMC Technical Support or your Authorized Service Representative, and quote this Knowledgebase article ID.

--Scenario 1

Verify using a simple command. We see the Power Shell returns the expected output and the false positive persists. 
Example




--Scenario 2

Use the following command to change the XMS name back to the expected name "xms":
From XMCLI, run:
rename xms-id=1 new-name="xms"

--Scenario 3

From PowerShell, run:
[ https://dell.to/33iKqtQ.ServicePointManager]::SecurityProtocol = [ https://dell.to/33iKqtQ.SecurityProtocolType]::Tls12      ===> This sets the connecting TLS version to 1.2.
New-XtremSession -XmsName (XMS IP address)                                                                                 ===> Enter the IP address for the XMS after XmsName.  
Get-XtremBBUs                                                                                                                                       ===> This is just to verify functionality.    
***Please note that the above SecurityProtocol command is valid on a per-session basis, and is not persistent.  This command will be required every time a new session is created.


If the above solutions do not resolve the issue...

Verify the XMS version. If it is an early 6.x version, an upgrade to XMS 6.2.0 or above is recommended. A Service Request can be opened with Dell EMC Support to request an XMS-only upgrade..

Transport Layer Security (TLS)   and its predecessor, Secure Sockets Layer (SSL), which is now deprecated by the Internet Engineering Task Force (IETF)   are cryptographic protocols that provide communications security over a computer network.
The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. When secured by TLS, connections between a client (e.g., a web browser) and a server (e.g., https://dell.to/3FcdwYU) have one or more of the following properties:
 

• The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session (see   TLS handshake). The server and client negotiate the details of which encryption algorithm and cryptographic keys to use before the first byte of data is transmitted (see   Algorithm below). The negotiation of a shared secret is both secure (the negotiated secret is unavailable to eavesdroppers and cannot be obtained, even by an attacker who places themselves in the middle of the connection) and reliable (no attacker can modify the communications during the negotiation without being detected).
• The identity of the communicating parties can be authenticated using public-key cryptography. This authentication can be made optional, but is generally required for at least one of the parties (typically the server).
• The connection is reliable because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.

Client-server applications use the TLS protocol to communicate across a network in a way designed to prevent eavesdropping and tampering.
Since applications can communicate either with or without TLS (or SSL), it is necessary for the client to indicate to the server the setup of a TLS connection. One of the main ways of achieving this is to use a different port number for TLS connections, for example port 443 for HTTPS.
Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure. The protocols use a handshake with an asymmetric cipher to establish not only cipher settings but also a session-specific shared key with which further communication is encrypted using a symmetric cipher. During this handshake, the client and server agree on various parameters used to establish the connection's security:
 

• The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and the client presents a list of supported cipher suites (ciphers and hash functions).
• From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.
• The server usually then provides identification in the form of a digital certificate. The certificate contains the server name, the trusted certificate authority (CA) that vouches for the authenticity of the certificate, and the server's public encryption key.
• The client confirms the validity of the certificate before proceeding.
• To generate the session keys used for the secure connection, the client either:
  • encrypts a random number with the server's public key and sends the result to the server (which only the server should be able to decrypt with its private key); both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session
  • uses Diffie Hellman key exchange to securely generate a random and unique session key for encryption and decryption that has the additional property of forward secrecy: if the server's private key is disclosed in future, it cannot be used to decrypt the current session, even if the session is intercepted and recorded by a third party.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the session key until the connection closes. If any one of the above steps fails, then the TLS handshake fails and the connection is not created.
 
TLS and SSL do not fit neatly into any single layer of the OSI model or the TCP/IP model. TLS runs "on top of some reliable transport protocol (e.g., TCP)," which would imply that it is above the transport layer. It serves encryption to higher layers, which is normally the function of the presentation layer. However, applications generally use TLS as if it were a transport layer, even though applications using TLS must actively control initiating TLS handshakes and handling of exchanged authentication certificates.

When the correct library module is installed, and Power Shell commands are resulting in the above fault - review the REST log of the XMS. The messages and associated codes of 200/400 (for example) can validate functionality. The above observed error message can be determined a false positve because valid REST replies identified from XMS logs.

--(Scenario 3)  Similar to the issue in SFDC 12686, the REST log on the XMS does not indicate any attempt to connect, and therefore, there are no failures associated with the customer's attempts seen in the logs.  Again, this is due to the initial connection being blocked by the version of TLS in use.  You can generally search the /var/log/xms/audit.log on the XMS to see if the weak ciphers script has been run in the past.