08-20-2014 07:42 PM
Environment: Windows 2008R2 Master, 2012 Media servers, NBU 126.96.36.199
I'm attempting to reconfigure an existing media server (gs-ms01.domain.local) with MSDP to have an additional workload server (es-ms01.domain.local) so I can perform optimized duplications using storage lifecycle policies between the two. gs-ms01 has the data and needs to replicate it to es-ms01. I'm doing this on a number of other media servers in the environment currently with success. However, on this particular media server (which has no other partner media servers currently), when I attempt to add credentials via the credentials dialog I get "Unable to add/update/delete credentials. server is shut down."
I verified firewall ports are open as appropriate between the servers, and from es-ms01.domain.local tried performing the credential add manually with tpconfig -add -storage_server gs-ms01.domain.local -stype PureDisk -sts_user_id nbumsdp -password sanitized
From there, I get "failed to open server connection to type PureDisk server gs-ms01.domain.local Error = 2060023
server is shut down
Authorization failed for OpenStorage server gs-ms01.domain.local"
I ran netstat -ano | find "SYN" and found that es-ms01 wants to talk to gs-ms01 on 443. gs-ms01 isn't listening, however, as evidenced by netstat -ano | find "443" on that end during another test of the operation.
I tried adding es-ms01 as an alternate to gs-ms01 in the credentials dialog and that succeeded. I was hoping I could do a "pull" move of the data as described in numerous duplication articles, but that didn't work, returning error "Requested media server does not have credentials or is not configured for the storage server (2107)". I attempted to alter COMMON_SERVER_FOR_DUP behavior, which also didn't allow for successful SLP usage (same error). I then came across TECH206553 which indicates that, despite all that talk about "pull" duplications throughout the documentation, apparently that's not really going to work out in an optimized dupe scenario, at least the way I read it. Someone please correct me if I'm reading it wrong and there's more immediate hope along this path.
Followed up with bpclntcmd -hn and bpclntcmd -ip in both directions and things look good for short name and fqdn. I also tried adding another media server to gs-ms01 and had the same result.
Additional reading indicated that the fact that the password for the dupe pool has an @ symbol in it may be related to the problem, but it's unclear as this is a Windows environment and the articles I saw were mentioning other operating systems specifically.
So at this point, I have a need to optimized duplicate between the MSDPs, and it appears that to do so I'll need to get the gs-ms01 credentials added to es-ms01. There's data on the gs-ms01 MSDP, so I'd rather not nuke it if possible, but that would be a (reluctant) option. Is it possible to do a "pull" optimized duplication via SLP? Typically I create/maintain MSDP via the GUI. Is there something else that's stupposed to be happening behind the scenes besides the tpconfig for this that maybe didn't happen in the first place? What are next steps for troubleshooting this?
Thanks in advance!
08-21-2014 12:03 AM
I have faced this error in our envirnment, let me the check the incident docs . In the meantime kindly confirm whether media server/storage server is active for disk
08-21-2014 01:10 AM
08-21-2014 05:47 AM
The correct license keys are in place (same throughout the environment). Backups are running fine on the MSDP. It's just the credential add that isn't working.
08-21-2014 05:51 AM
I had one similar to your problem. I tried to configure MSDP in a Media Server, but when I put the credential and sent to create the Storage Server, appeared that same message. To solve this problem, I realized the steps below:
1. Go to the folder: Program Files \ Veritas \ PDDE
2. Run the command: PDDE_deleteConfig
3. Perform the configuration creation of MSDP again.
NOTE .: Create the folder: MSDP disk that Deduplication is configured; Check the license Dedup the server (as indicated above);
08-21-2014 06:16 AM
Thanks - I'm hoping to avoid deleting the MSDP though. As I've indicated, the licensing is correct and backups are successfully going to the MSDP.