Unable to connect to untrusted server
-
vendredi 7 janvier 2011 09:37
I am running DPM2010 on Win2k8R2.
On new years day the server lot connectivity to several client servers on untrusted domains./
No changes were made
The client servers are running Win2k3 SP2, DPM agent 3.0.7696.0
I'm getting an error 'Data Protection Manager Error ID:318
The Agent Operation failed because DPM was unable to identify this computer account for server.domain.local
No Mapping Between account names and security IDs was done
Verify that both server.domain.local and the domain controller are responding.
I am able to access both ways, no firewalls exist, i have tried restarting both the clients and the DPM server. I have rerun setdpmserver with isnondomainserver and appropriate options, using the FQDN of the DPM ser.ver
The clients and DPM server are on different subnets and the cients are not able to resolve the NetBIOS name of the DPM server
Any ideas where I can go?
Sections from the DPMRA logs are
0A1C 10FC 01/06 21:06:33.692 04 cmdproc.cpp(1989) [00C1E568] 59B8A366-B50E-4B05-9B48-1228505A0848 WARNING Failed: Hr: = [0x800706ba] CCommandProcessor::CreateInstance, CCIE Failed, mqi.hr: 0x800706ba
0A1C 10FC 01/06 21:06:33.692 04 cmdproc.cpp(2007) [00C1E568] 59B8A366-B50E-4B05-9B48-1228505A0848 WARNING CCommandProcessor::CreateInstance, Retrying CCIE
Thanks
Mark
Toutes les réponses
-
vendredi 7 janvier 2011 10:54Modérateur
Hello Mark
Need some clarification.
Did you use -IsNonDomainServer option with a new UserName this time?
This posting is provided "AS IS" with no warranties, and confers no rights -
vendredi 7 janvier 2011 14:21Modérateur
Hi Mark,
You said the clients are not able to resolve the NetBIOS name of the DPM server, is this be design in your network, or a symptom? Do you have WINS servers? If you have WINS servers and you cannot resolve the NetBIOS name of the DPM server from a client on another subnet, the DPM problem is likely a symptom of a WINS issue.
If you don't have WINS servers in your network you could either use lmhosts files on the clients to provide NetBIOS name resolution of the DPM server or use the –productionServerDnsSuffix switch in your SetDPMServer command. For example, SetDpmServer.exe –dpm servername server01.domain.ad -isnondomainserver -username user01 -productionServerDnsSuffix dmz.local
See this blog http://scdpm.blogspot.com/2010/08/attach-untrusted-machines-using-fqdn.html
-
dimanche 9 janvier 2011 20:22
Thanks Prateek,
ok, these servers have worked for about three months now (passwords configured not to expire) but stopped on Jan 1st. As mentioned above, no changes we were shutdown for the christmas break)
I have tried the productionserverdnssuffix with no improvement (restarted DPMRA (not the server). From the documentation this is only required if the server has more than one DNS suffix, which this one doesn't.
Yes, used -isnondomainserver option with the username as required.
lmhosts hasn't helped either, and from what I can gather, this is only required if you enter the netbios name and not the fqdn of the protection server.
Any other ideas?
-
dimanche 9 janvier 2011 20:51
Have resolved it, simply re-attaching via the DPM shell has sorted it.
attach-nondomainserver [fqdn of dpm server] -psname [fqdn of protected server] -username [username]
Why would this be lost?
- Proposé comme réponse Prateek Sharma [MSFT]Microsoft Employee, Moderator lundi 10 janvier 2011 06:58
- Marqué comme réponse MarcReynoldsModerator lundi 10 janvier 2011 16:04
-
vendredi 25 février 2011 18:34Thanks. I had this same issue and re-attaching the server via the powershell script solved it. I believe it was possibly due to the password expiring in our case.
Jeff Graves, ORCS Web, Inc. -
mardi 14 février 2012 22:30
Helllo all!
I have a same trouble
9AFB0B63-C4C2-4170-9439-A2F094B8E54C WARNING Failed: Hr: = [0x800706ba] CCommandProcessor::CreateInstance, CCIE Failed, mqi.hr: 0x800706ba 0AA8 12AC 02/14 22:23:11.671 04 cmdproc.cpp(2007) [00000000008D5A10] 9AFB0B63-C4C2-4170-9439-A2F094B8E54C WARNING CCommandProcessor::CreateInstance, Retrying CCIE 0AA8 12AC 02/14 22:23:17.671 04 cmdproc.cpp(1989) [00000000008D5A10] 9AFB0B63-C4C2-4170-9439-A2F094B8E54C WARNING Failed: Hr: = [0x800706ba] CCommandProcessor::CreateInstance, CCIE Failed, mqi.hr: 0x800706ba 0AA8 12AC 02/14 22:23:17.671 04 cmdproc.cpp(2007) [00000000008D5A10] 9AFB0B63-C4C2-4170-9439-A2F094B8E54C WARNING CCommandProcessor::CreateInstance, Retrying CCIE 0AA8 12AC 02/14 22:23:23.671 04 cmdproc.cpp(2017) [00000000008D5A10] 9AFB0B63-C4C2-4170-9439-A2F094B8E54C WARNING Failed: Hr: = [0x800706ba] : F: lVal : hr 0AA8 12AC 02/14 22:23:23.671 04 cmdproc.cpp(2242) [00000000008D5A10] 9AFB0B63-C4C2-4170-9439-A2F094B8E54C WARNING Failed: Hr: = [0x800706ba] : F: lVal : CreateInstance( strCmdTarget, clsidTarget, hrDLS, (IUnknown **)&pAgentCommand, (pCommand->GetSenderToken() == 0), pCommand->IsNonDomainAgent(), fIsNonADMachine, cmdTargetIP ) 0AA8 12AC 02/14 22:23:23.671 04 cmdproc.cpp(2482) [00000000008D5A10]
The problem was a expired passwords on non domain servers. Just change the passwords and all early added agents get a "OK" status.- Modifié Sqaer mardi 14 février 2012 22:58
-
mercredi 4 avril 2012 22:10
Just spent 6 hours trying to figure out why our non domain clients all stopped working at the same time. Figured it was a communication/firewall problem to begin with but after a long time of looking at it realised that the passwords can expire both on the client and on the DPM server itself. Now set them to never expire on the DPM server as well and all is well. Messaging and informational logging was virtually non-existent and properly unimpressed at the amount of time it has cost me to resolve this. Afraid that is my generic impression of DPM 2010, kind of cool but unpolished and not hugely robust.
Meint
- Proposé comme réponse Patrik Hansson mardi 8 mai 2012 11:47
-
mardi 8 mai 2012 11:48
Just spent 6 hours trying to figure out why our non domain clients all stopped working at the same time. Figured it was a communication/firewall problem to begin with but after a long time of looking at it realised that the passwords can expire both on the client and on the DPM server itself. Now set them to never expire on the DPM server as well and all is well. Messaging and informational logging was virtually non-existent and properly unimpressed at the amount of time it has cost me to resolve this. Afraid that is my generic impression of DPM 2010, kind of cool but unpolished and not hugely robust.
Meint
Hade the same problem, user on DPM-server had expired password and the "user most change password at next logon" checked.
Unchecked it and set password never expires instead. Was able to connect to agent right after.- Modifié Patrik Hansson mardi 8 mai 2012 12:01 spelling
-
vendredi 18 mai 2012 20:11
For protected servers in an untrusted domain, dpm creates local accounts on protected server. You can prevent having to re-attach by setting the local account passwords to never expire (local users and groups->users->dpm agent account).
Also instead of re-attaching, you can run:
On Protected Server: setdpmserver -dpmservername <name of dpm server> -isNonDomainServer -UpdatePassword
On DPM Server: .\Update-NonDomainServerInfo.ps1
This updates the password of the local dpm agent account. If you set the local account to never expire then you should never have to run the updatepassword or attach command
-Newbs
- Proposé comme réponse DenverTechGuy vendredi 18 mai 2012 20:11
.png)
