I encountered this problem recently and with only access to the restore logs, it took me a while to figure out that the root cause is as simple as restore destination pointing to the wrong box!
Longer story:
I have the following evidence on hand:
NCFGRE log from SQL Server
22/06/2018 08:49:55.508 [Debug] NB 51216 ncfrai 158 PID:4960 TID:9240 File ID:352 [No context] 4 [[fsys\spsv3] ] <from Consumer::initializeResource> WNetAddConnection2 returned: 67. Either connection failed or the network path is not accessible (../BEDSContext.cpp:159)
22/06/2018 08:49:55.509 [Debug] NB 51216 ncfrai 158 PID:4960 TID:9240 File ID:352 [No context] 1 [ResourceChildBEDS::_attach()] FS_AttachToDLE() Failed! (0xE0008488:Access is denied.) (../ResourceChild.cpp:674)
Additional environment info
- SharePoint 2016 front-end server and SQL back-end server are both VMWare virtual machines.
- SharePoint farm is backed up using VMWare policy with Enable SharePoint Recovery option checked.
- Now we need to restore some granular items.
Assuming you have experience with NetBackup SharePoint agent before, do you notice anything suspicious?
Well, I didn’t initially.
NetBackup always generates NCFGRE log in the SQL Server for as long as I remember. Until… SharePoint 2016 came along.
To connect to SharePoint 2016, NetBackup doesn’t use custom API anymore, instead it uses a standardized method called SharePoint Server Object Model (SSOM). With that, the granular recovery process has been moved to the SharePoint front-end server. It is no longer on the back-end server.
If you notice, the NCFGRE log in my case was created in the SQL Server, so that should raise a suspicion. Yes, this happens if the restore destination is pointing to the SQL Server.
Just bear this in mind: As far as NetBackup is concerned, SharePoint restore destination must always point to the SharePoint front-end server. This will solve the problem I mentioned at the beginning.
W 