Thursday, 15 February 2018

TPDSrm.exe


TPDSrm.exe


This post is about an issue I faced recently when integrating VMware Site Recovery Manager on a customer site. As part of the integration you need to get both SRM servers to trust the 3PAR certificate. There is a command to do this but for some reason it was not working for me. Someone else out there may have this issue so hopefully this will save you an hour or two troubleshooting!

The command syntax is as follows:


TPDSrm.exe validatecert –sys <ip address of 3PAR> –user username –pass password

So the symptoms were as follows:

If you just type in TPDSrm.exe and press enter you get the help page. It shows you the various options. I then crafted the full command and entered it but it came back with the help page again! I checked for typos, there were none. I tried the other SRM server and got the same result. I then upgraded the SRA software from 6.5 to 6.5.3 and it was no better! 

I was really scratching my head at this stage. The only way I could get a different reaction was to put <> around some of the values, just to prove it was reading the command, this gave an error of course. Other commands to showcache or listcerts works fine! There was nothing to show but at least it ran the command!

I then tried substituting crap into the value fields as follows:

TPDSrm.exe validatecert –sys george –user bob –pass bob

This got me nowhere, it was as if it didn't matter what the commands I tried there was something else going on here. I was about ready to call it a day and log a support call when I tried typing out the commands one at a time like this:

TPDSrm.exe 

TPDSrm.exe validatecert 

TPDSrm.exe validatecert –sys george 

TPDSrm.exe validatecert –sys george –user bob 

TPDSrm.exe validatecert –sys george –user bob –pass bob

When I typed in the final command it actually did something and came back to say it couldn't find the system. I then went back and typed in my original command and got the help screen again! Then I typed out the command is 5 stages as listed above, but with valid data (although with a fake password as I wanted to rule out a "!" as causing a problem. It tried to connect and failed. I then used the correct password after updating it to remove a "!" just in case and it connected fine. The cert was trusted and I could repeat this process on the other server. 

Conclusion - either a "!" in the password or a copy / paste issue is the only conclusion I could reach. I don't think it was the password but perhaps the notepad file I used to stage the command, copied over RDP, corrupted the command in some way? I did try typing the whole command and this failed too but after so many attempts maybe I didn't try this. 

Anyway, strange one, might get someone out of a hole in the future.