IDR can't see Media Server

[MitchR]

My v12.5 IDR restore of a 2008 server keeps reporting the following two errors (one, then the other right in a row) when at the "Connect to Media Server" page:

Unable to add service account to the local Administrators group
(http://entsupport.symantec.com/umi/V-290-192)

Unable to establish connection with the media server
(http://entsupport.symantec.com/umi/V-290-193)


Lots of ugly details:
My Media Server is a Windows 2000 Standard Server, running BE 12.5, patched to the latest.
My restore server is a Windows 2008 Standard Server, using an IDR boot CD with the latest .DR file on it.
My Media Server does not have a running firewall.
Both servers are on the same subnet - there is no firewall between them.
Our network does NOT have WINS - which might be part of the the problem?
  See last post in the thread:  https://www-secure.symantec.com/connect/forums/idr-not-able-see-media-server

Earlier in the IDR Wizard, at the "Select Recovery File", I can select "Configure Network", and all appears fine. 
I'm using DHCP - and can ping the restore server from the Media Server just fine.
At that same screen, I can "Browse for Disaster Recovery Files" - and can successfully map drives & browse to my Media Server.
The .DR file reads just fine (both off the CD & mapped drive), and has correct partition information.
At the "Select Restore Method" page, I select "remote media server" - which I must do for our network. 
At the "Connect to Media server page, I've tried all combinations of the following:
-Server name of MediaServerName or IP
-Domain name of "domain" or "domain.local"
-User name of "BESA" or "domain\BESA" or "TestDomainAdminAccount"

When I check the security event log on the media server, I do not see failure logs when the errors appear.

[MitchR]

Found the following in the IDR log:


[0968] [07/14/2009 23:43:57]: Unable to add service account to the local Administrators group
[0968] [07/14/2009 23:45:39]: Error 2202 returned from WNetAddConnection2 when trying to connect to resource \\MediaServer\c$.
Error Message: The specified username is invalid.[0968] [07/14/2009 23:45:39]: Trying to connect to media server using resource name \\192.168.1.32\c$...
[0968] [07/14/2009 23:45:39]: Error 2202 returned from WNetAddConnection2 when trying to connect to resource \\192.168.1.32\c$.
Error Message: The specified username is invalid.[0968] [07/14/2009 23:45:39]: Trying to connect to media server using resource name \\192.168.100.32\c$...
[0968] [07/14/2009 23:45:39]: Error 2202 returned from WNetAddConnection2 when trying to connect to resource \\192.168.100.32\c$.
Error Message: The specified username is invalid.[0968] [07/14/2009 23:46:38]: Unable to add service account to the local Administrators group
[0968] [07/14/2009 23:46:39]: Error 2202 returned from WNetAddConnection2 when trying to connect to resource \\192.168.1.32\c$.
Error Message: The specified username is invalid.[0968] [07/14/2009 23:46:39]: Trying to connect to media server using resource name \\192.168.1.32\c$...
[0968] [07/14/2009 23:46:39]: Error 2202 returned from WNetAddConnection2 when trying to connect to resource \\192.168.1.32\c$.
Error Message: The specified username is invalid.[0968] [07/14/2009 23:53:00]: Unable to add service account to the local Administrators group
[0968] [07/14/2009 23:53:02]: Error 2202 returned from WNetAddConnection2 when trying to connect to resource \\MediaServer\c$.
Error Message: The specified username is invalid.[0968] [07/14/2009 23:53:02]: Trying to connect to media server using resource name \\192.168.1.32\c$...
[0968] [07/14/2009 23:53:02]: Error 2202 returned from WNetAddConnection2 when trying to connect to resource \\192.168.1.32\c$.
Error Message: The specified username is invalid.[0968] [07/14/2009 23:53:02]: Trying to connect to media server using resource name \\192.168.100.32\c$...

[MitchR · Accepted solution]

After building a test lab, and spending a few dozen hours on this problem, I've found two things that were causing problems:

First was a a security setting in Group Policy.  Note that this setting is recommended by Microsoft for high security networks. 

In our case, it was a setting applied to the Domain Controller - not the BackupExec server, nor the client I'm trying to restore.  In Group Policy, it's under:
-Computer Configuration
-Windows Settings
-Security Settings
-Local Policies
-Security Options
"Network security: LAN Manager authentication level"

If this setting is set to "Send NTLMv2 response only\refuse LM & NTLM", Backup Exec can't use IDR to restore a client.
In my lab, the next least restrictive setting works OK for me: "Sent NTLMv2 response only\refuse LM"

Apparently Symantec is using some older protocols in their IDR process.

Secondly, I found that NetBIOS is required by the IDR process.  This is turned on/off on your NIC's TCP/IP settings, advances, WINS, "Enable NetBIOS over TCP/IP".
This means that you can't use IDR in an environment that restricts NetBIOS.

Hope this note helps the next poor soul to have this issue....

[Roper]

I could not push the RAWS to my other servers because of the use of NTLM.  I support government computers and NTLM is refused and only NTLMv2 is allowed.  Is there any other way the RAWS can authenticate (change settings) with the BackupExec Server or visa versa (for pushing updates and RAWS)?

[MitchR]

From what I've seen, those of us with high security network are stuck until Symantec decides to start using more modern protocols.
 

[Roper]

I hope that is soon too, because Symantec's Remote Agent for Windows (v12.5) shows a medium vulnerability.  That vulnerability will start showing up on every security scan in the Navy.  I show 14 updates for RAWS but can't install them from the main server, and I do not see a way to install them on each remote server manually.

[teiva-boy]

 I wouldnt say that it's because of not using modern protocols...  

Take a look at the majority of networks, and they are NOT using NTLMv2.  What Symantec did was make a choice in what would benefit the majority of users, not all of the users.  You folks just happen to be at the short end of the stick..

Why dont you tell Microsoft to enable NTLMv2 via windows updates automatically, then I think other vendors will follow suit.  Sometimes compatibility trumps security.