After installing WFA on the system (win2008R2V M) I am able to connect to the netapp controllers (3 * 8x-7m simulators-vm's), to the LDAP server (win2008 DC-vm) but not to the DFM server (win2008-vm).
Diagnosed this in Execution -> Credentials -> New -type: DFM
DFM/OnCommand 5 itself is functioning okay by the way (ie. prov./prot mgr and PA are working okay).
After installing wfa_oc5setup.exe I still have connection failure from WFA server to DFM server presented as follows:
failed to connect to DFM: dfm.vmdomain.local. Message: No connection could be made because the target machine actively refused it ip-address:22.
Disabled firewall for diagnostic purposes, but also to no solution unfortunately.
Only thing I had running was putty (SSH) on DFM server, but even after stopping all putty sessions, no WFA to DFM connection possible.
I did not understand your question to the full extent.
Is the problem with testing the credentials to the DFM or with acquiring information from it?
If it is the former - Use your own user/password to the DFM and SSH needs to be enabled and available on the DFM.
Does your DFM has SSH on it?
If it is the latter - No credentials (And no SSH) are needed.
After you run OC5Setup (Did it finish successfully?) you can set a data source in the "Datasources" screen.
Just make sure you replace the default user/pass in that screen with "wfa" and "Wfa123" respectively.
Then - try "Acquire Now" and see if it works. Don't change the port there - The acquisition works through 2638.
BTW - This process is fully documented in the WFA installation and Setup guide with additional commentary in the
tips and troubleshooting guide. Have you gone through these two documents?
The problem seemed to be on both parts, testing the credentials to DFM and acquiring info.
but, the acquiring info problem is solved..... problem seemed to be related to installing the oc5setup.exe on 64bit platforms (installation was defaulting to \Program Files (x86)\Netapp\DataFabric Manager\DFM which seems to be empty instead of installing to C:\Program Files\NetApp\DataFabric Manager\DFM ). So after setting up Data Sources, I am able to Acquire NOW.
I indeed installed conform WFA installation and Setup guide v1.1 (feb.28, 2012 rev.1.6) - but cannot find the tips and troubleshooting guide you mentioned.
As for the credentials part.... still no luck - Changed the security option on the DFM server from RSH to SSH, but still same problem as mentioned " failed to connect to DFM: dfm.vmdomain.local. Message: No connection could be made because the target machine actively refused it ip-address:22. ".
Tried credentials with Domain as well as local administrator accounts and offcourse with the wfa account from the WFA server to the DFM server; none of them succesfully unfortunately.
First, let's set the records straight about OC5Setup - It is not installing anything. It needs to be on the OC5 and when executed you should select the DFM folder (Based on where it was installed,
so obviously the default path is only a suggestion - Some install it at a different drive). When it finds it creates the internal user in the OC5 DB that allows WFA to acquire.
Regarding the credentials for the DFM - DFM credentials are needed only for running commands which via SSH on the DFM. There's a good chance that you won't need it for starting with WFA.
It has no impact on acquisition.
Obviously we would like to take a closer look at your issue.
Here's a link to the troubleshooting guide:
Is there a clarification on this? The install document has a comment that indicates if you want to use Protection Manager, Provisioning Manager or Service Catalog, you need to configure the DFM credentials. Yet we get this same error when we attempt to do so. Not sure why port 22 is being used for this. Is this comment in the install document wrong?
FYI, I ran into this same issue: Message: No connection could be made because the target machine actively refused it ip-address:22.
Windows host, 64-bit VM, Server 2008. Installation of FreeSSHd and creation of a separate SSH user was MANDATORY. If the user was not created I would receive "Auth null" error when trying to test connectivity through credentials.
I'm getting the same error:
It is obviously using port 22. My DFM server is a Windows 2008 R2 VM and the firewall is temporarily disabled. Port 22 is normally SSH. Does that mean I have to add an SSH service to my DFM server? Was it switched to ZAPI as the previous poster mentioned and the "ports required" section below suggests? What is ZAPI and do I need to add this to my DFM server (Windows)?
The section about Credentials in the same guide says nothing about adding entries for either DFM or vCenter, just storage systems. The only reason I started looking into this is because adding DFM to Credentials is briefly mentioned in the NetApp University video on installation. It still isn't clear to me what functions this would enable.
I will try to clarify this while asking you a couple of questions.
First, Credential check is indeed done via SSH. If you'd like to achieve that the port should be open and an SSH server should be on the other
side (All the more so relevant for Windows based DFMs).
DFM has 2 different uses in WFA:
1) Data acquisition - For which we use the OCSetup tool to create a proprietary user for WFA access in DFM database (Default credentials are wfa/Wfa123)
2) Running commands (Such as Create Dataset, Add Volume to Dataset, etc.) - For that the credentials are needed and the activity is done via SSH.
Which credentials are required for #2? For example, credentials that are used to login to the DFM UI, providing that user is part of the DFM administrators group.
Now, some questions:
1) What is this user you configured for checking connectivity? Is this user a DFM user?
2) Can you try putting the IP instead of the hostname? Just trying to isolate the issue you are facing.
Best regards, and happy 2013!
That information helps. Thank you. To answer your questions...
1) What is this user you configured for checking connectivity? Is this user a DFM user? The user is just an SSH user, not a DFM user. So you are saying the SSH user/password I setup should match the user/password of an existing DFM user? If so, this is probably the issue.
2) Can you try putting the IP instead of the hostname? Just trying to isolate the issue you are facing. Same error with IP address.
Can you please try to confirm that? Replace the user to one known by the DFM?
I will log a case on that issue, as I would have expected to get "Invalid credentials" rather than "No credentials".
We are invoking NaSsh-Invoke from the Powershell toolkit and doing "dfm:about", so obviously an SSH user will go in, but will not be able
to connect to the DFM.
That worked! Here are the three scenarios and their outcomes. Feature requests are in BOLD.
Enter credentials of user unknown to SSH service. Error is "Incorrect credentials for <name/IP>." This error should read "Incorrect SSH credentials for <name/IP>."
Enter credentials for user known to SSH service but unknown to DFM. Error is "No credentials were found." This error should read "Incorrect DFM credentials for <name/IP>."
Enter credentials of user known to both SSH and DFM. Message is "Connection succeeded - credentials are valid."
For the benefit of others, my setup is as follows:
Windows Server 2008 R2
OnCommand Unified Manager 5.1
Free version of Copssh https://www.itefix.no/i2/content/copssh-free-edition
NOTE: If you setup a domain user in Copssh you don't use the domain in WFA credentials. For example, if you specified DOMAIN\User in Copssh you will type User into WFA credentials area.
Windows Server 2008 R2
OnCommand Workflow Automation 2.0
This SSH business is a real pain in the ass for Windows environments, especially since PowerShell is perfectly capable of remote command execution. Either WFA needs to use PowerShell for DFM commands in future version or DFM needs to include an SSH service in future versions!
Thanks again for your help,
I thank you for your comments.
I opened a bug on the "No credentials" and the suggestion to fine tune the issues of incorrect one (DFM/SSH) - The latter with obvious lower priority.
Regarding SSH usage with DFM - We are replacing SSH usage wherever possible (Where ZAPI is available), However, there are currently still some cases
where SSH must be used for the lack of other APIs.
Great write-up Daniel. Your workaround fixed my issue.
It should also be noted that the account you activate with copssh must also match that of the account provided to the ocsetup.exe. This might create issues for some admins whose domain rules require more complex passwords, as the ocsetup will not allow any special characters in the password provided!