Sharepoint 2010 GRT restore failing with Status 37

[smckelvey]

I'm sure this has something to do with the fact that the client is showing up in the BAR with it's FQDN. I don't know why that is though, and I don't seem to be able to change it.

I know I tested this when I first deployed about a year ago. And the client name on the Master Server is not the FQDN. So I'm not sure what changed.

• I tried changing the client name in it's Client Properties in the BAR. that didn't work.
• I tried restoring from the master using the non-fqdn client names, which ultimately results in a status 37.
• i tried restoring from the client (i.e. Front end server) using the FQDN as the source client, and that results in the error that there are no images available in the BAR console.
• I tried restoring from the client (i.e. Front end server) using the non-FQDN as the source client, and I can see the images, but get a 37 when restoring.

I see this in one NBWIN001 log:

16:02:08 client wtp-sp2010-fe1 peername wtp-sp2010-fe1.wtplaw.com is invalid for restore request
16:02:10 INF - Server status = 37

Help appreciated. If there are particular logs that would be helpful, please let me know and I'll get them.

[RamNagalla]

keep the below touch file in the master server and try the restore with short name only.

/usr/openv/netbackup/db/altnames/No.Restrictions   --> for unix master

install_path\NetBackup\db\altnames\No.Restrictions  ----> windows master.. ( make sure it has no .(dot) extenctions)

[smckelvey]

I have that file already (no.restrictions).

I also forgot to mention:

• WIndows Server 2008 Master Server
• Netbackup is 7.5.0.4 on both master and clients
• Sharepoint is a 3 server farm (all Windows Server 2008r2) with a front end, SQL and app server.
• All backups are configured according the Netbackup Sharepoint Guide, and point to the front end server.

[RamNagalla]

what is the entiry in the client for below registy key.. does it have short name or FQDN?

HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\Config\Client_Name

does the master server able to resolve both short name and FQDN.

show us the output of below  commands

from master :-

bpclntcmd -ip <clientip>

bpclntcmd -hn <client short name>

bpclntcmd -hn <client FQDN>

from Client :-

bpclntcmd -self

bpclntcmd-pn 

bpclntcmd -ip <clientip>

bpclntcmd -hn <client short name>

bpclntcmd -hn <client FQDN>

[smckelvey]

Nagalla:

Registry entry on the client is currently the short name, but it used to be FQDN, before I changed it yesterday from the Client Properties in the BAR when I started to troubleshoot this problem.

The Master server can resolve both names.

Your requested outputs from master:

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -ip 10.128.0.150
host 10.128.0.150: wtp-sp2010-fe1.wtplaw.com at 2002:d8e6:7f12:8000:0:5efe:10.128.0.150
host 10.128.0.150: wtp-sp2010-fe1.wtplaw.com at 10.128.0.150
aliases:     wtp-sp2010-fe1.wtplaw.com     2002:d8e6:7f12:8000:0:5efe:10.128.0.150     10.128.0.150

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -hn wtp-sp2010-fe1
host wtp-sp2010-fe1: wtp-sp2010-fe1.wtplaw.com at 2002:d8e6:7f12:8000:0:5efe:10.128.0.150
host wtp-sp2010-fe1: wtp-sp2010-fe1.wtplaw.com at 10.128.0.150
aliases:     wtp-sp2010-fe1.wtplaw.com     wtp-sp2010-fe1     2002:d8e6:7f12:8000:0:5efe:10.128.0.150
    10.128.0.150

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -hn wtp-sp2010-fe1.wtplaw.com
host wtp-sp2010-fe1.wtplaw.com: wtp-sp2010-fe1.wtplaw.com at 2002:d8e6:7f12:8000:0:5efe:10.128.0.150
host wtp-sp2010-fe1.wtplaw.com: wtp-sp2010-fe1.wtplaw.com at 10.128.0.150
aliases:     wtp-sp2010-fe1.wtplaw.com     2002:d8e6:7f12:8000:0:5efe:10.128.0.150     10.128.0.150

Your requested outputs from client:

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -self
gethostname() returned: wtp-sp2010-fe1
host wtp-sp2010-fe1: wtp-sp2010-fe1 at 2002:d8e6:7f12:8000:0:5efe:10.128.0.150
host wtp-sp2010-fe1: wtp-sp2010-fe1 at 10.128.0.150
aliases:     wtp-sp2010-fe1     2002:d8e6:7f12:8000:0:5efe:10.128.0.150     10.1
28.0.150
getfqdn(wtp-sp2010-fe1) returned: wtp-sp2010-fe1.wtplaw.com

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -pn
expecting response from server balt-srvr-nbu
wtp-sp2010-fe1.wtplaw.com wtp-sp2010-fe1 10.128.0.150 59548

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -ip 10.128.0.150
host 10.128.0.150: wtp-sharepoint.wtplaw.com at 10.128.0.150
aliases:     wtp-sharepoint.wtplaw.com     10.128.0.150

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -ip 10.128.0.150
host 10.128.0.150: wtp-sharepoint.wtplaw.com at 10.128.0.150
aliases:     wtp-sharepoint.wtplaw.com     10.128.0.150

[Marianne]

NBU is case sensitive. File name must be No.Restrictions with no extention.

If you open Windows Explorer and navigate to C:\Program Files\Veritas\NetBackup\db\images, which folder name(s) do you see for sharepoint client?

[smckelvey]

Marianne:

• the No.Restrictions file is written correctly. i just took some liberty while typing. As I recall I had to do that as fix for something else a long time ago.
• The folder name for the client is the short name.

[Marianne]

What we need now is bprd log file on the master server.

If bprd log folder does not exist, create folder under C:\Program Files\Veritas\NetBackup\logs and restart NetBackup request service. Retry the restore.

Copy bprd log to bprd.txt and post as file attachment.

[smckelvey]

This is the message from the status window in the Client's BAR when I try to restore:

15:31:47 client wtp-sp2010-fe1 peername wtp-sp2010-fe1.wtplaw.com is invalid for restore request
15:31:49 INF - Server status = 37

And attached is a screenshot of the Restore window, in case I'm doing something wrong (but I'm just following the guide and my notes from when i first tested it).

[RamNagalla]

post the bprd log as requested by Marianne.

make sure VERBOSE in the master server is set to 5 before starting the restore and turn it off once the restore is failed.

[Marianne]

PLEASE! No level 5 log! Level 0 is perfectly fine for troubleshooting this error.

Symantec Support has tools to read level 5 logs... I don't...

[Will_Restore]

why does  bpclntcmd -ip 10.128.0.150  come back with wtp-sp2010-fe1.wtplaw.com on the Master and wtp-sharepoint.wtplaw.com on the Client?  that needs to be fixed.

[Will_Restore · Accepted solution]

also, see this technote

http://www.symantec.com/business/support/index?page=content&id=TECH177299

Cause

This problem can occur if there is a missing or inaccurate entry in the Distributed Application Restore Mapping settings in the host properties of the master server.

Solution

NetBackup catalogs backup images under the SharePoint front-end server name.  To allow NetBackup to restore SQL databases to the correct hosts in a farm, you must provide a list of the SharePoint hosts.

Ensure that all appropriate hosts are listed and that there are no typographical errors in any of the entries.

For more detail on the Distributed Application Restore Mapping setting, see the "Configuring restores for multiple SharePoint Server hosts" of the Symantec NetBackup for Microsoft SharePoint Server Administrator’s Guide referenced below.

[smckelvey]

Marianne:

I had to wait to restart services. But I just did this morning. Here's a bprd log from this morning. I only tried one restore from the BAR on the Sharepoint Front End server (wtp-sp2010-fe1).

[Will_Restore]

08:54:23.627 [4260.4240] <16> is_redirected_restore_allowed: One or more input parameters are invalid.
08:54:23.627 [4260.4240] <2> process_request: client wtp-sp2010-fe1 peername wtp-sp2010-fe1.wtplaw.com is invalid for restore request

have you followed my posts above?

[smckelvey]

wr:

not exactly sure what you are asking. But, yes, I've read your posts. I agree that the problem is the FQDN, and that's why I started this thread b/c I can't figure out how to change that. The short name is and always has listed in the Netbackup Admin Console. Unfortunately I don't recall what used to be listed in the "Netbackup Client Properties" of the BAR on the client, but I can say that it had the FQDN when I first identified this problem the other day. Additionally, I can change said name on the client, and the registry entry changes, but the "Destination Client for Restores" box in the "Specificy Netbackup Machines and Policy Type" is always grayed out and always has the FQDN.

Regarding your other post w/ a link to the Admin Guide, I believe that is already configured properly. But I'll check. As I said, I know I tested everything when initially setup, and i went through the guide at that time.

[Will_Restore]

Your client says its own IP resolves to a different name

  wtp-sharepoint.wtplaw.com

How does your client come back with that name --  Local hosts file?  Bad DNS entry?

Here's another technote that describes similar problem

http://www.symantec.com/business/support/index?page=content&id=TECH155673

Operation requested by an invalid server - status 37

Solution

This is typically a simple configuration or name resolution issue.

[smckelvey]

I'm not a sharepoint expert, but "wtp-sharepoint.wtplaw.com" is the correct name of the sharepoint farm. and it is in DNS.

I went back through the Distributed Application Restore Mapping (DARM) that you referenced via that technote. It was blank. I assume that I never entered any info because even upon re-reading, it appears to me that is only required to restore to a different server or Farm from where the backup was originally taken. But we did upgrade Netbackup and a new Master Server since this was originally configured and tested, so if there's anyway that could have wiped those settings, then that would be a possibility. But I suspect the former.

Regardless, I added the servers to DARM, and the restore is now working. 

I still don't understand why and how that FQDN is showing up on the client. nor what changed so that the restore stopped working. I do make mistakes, but none of our other servers have FQDN names, including the other two in the Sharepoint Farm.

Anyways, I'm thinking I'll leave well enough alone, and consider this resolved. Unless someone has some other concern.

As usual, thank you everyone for the help.

[Will_Restore]

>>I added the servers to DARM, and the restore is now working.

OK, that's great.  

Our SharePoint admin also has DNS alias though the client IP points to the hostname and not the alias. 

  hostname  A record ->  IP

  IP  PTR ->  hostname

  alias  CNAME ->  hostname