none
DPM 2012 UR3 Agent Update Error: HRESULT E_FAIL...DCOM Error RRS feed

  • Question

  • My DPM Server is Windows 2008 R2 SP1 with a locally installed SQL and DPM Server and fully patched. My Workstations are all Windows 7 Ultimate x64, fully patched. I have manually installed the DPM RTM Agent and pushed the UR2 update from the DPM Server without any challenges or issues. I have SCEP running with process exclusions for the DPM services on the WS and DPM Server. I’ve been running DPM 2012 RTM and then UR2 without any issues or challenges to-date.

    I have recently updated my DPM 2012 Server from UR2 to UR3 and pushed out all the Agent Updates, which appeared to go successfully from the DPM Console perspective. I spot checked a few systems, 1 workstation (WS) and 1 server, everything looked good. A couple of days after this I noticed 2 of my workstations failed backing up to Tape. I noticed the recovery options available for these WS’s have stopped updating hours after pushing the UR3 Agent update. The 2 WS’s I'm troubleshooting have a little different scenario. I have 2 other WS’s that were updated in the same manner and are working perfectly.

    Both WS cannot connect to the DPM Server and displays this DCOM Error:
    "ERROR:ERROR HRESULT E_FAIL has been returned from a call to a COM component."
    The 1st WS DPM Client has a Yelow Sign over-lay and "Administrator has not configured backups." when you hover over it.
    The 2nd WS does not the Yellow Sign over-lay.

    All the properties of the Local DPM Client Console 'Summary and Protected item'  tabs are not updated on the 1st WS but are on the 2nd WS.
    1st WS process:

    The Recovery Tab shows the available recover dates to choice from.
    I can expand one of the backup dates, folders and copy a file to this system.
    I can view my previous recovery Points from the console dating back to when I updated the Agents.
    I’ve validated the DCOM settings on both WS's compared to a WS that is working, they are the same.
    I uninstalled the agent manually, then copied and reinstalled the new UR3 Agent Version with the same outcome.
    I uninstalled the new version and reinstalled the previous version, same error.
    I then proceeded with upgrading UR2 agent version installing the UR3 version over the top, same error.
    I logged on to this WS as the Domain Admin, removed and reinstalled the UR3 version, same error.
    I removed, applied and then re-added the DPM server to the local WS DPM and DCOM Groups.
    I removed, applied and then re-added the WS from the Groups on the DPM Server.
    I’m able to see, ping and view other backup folders presented on the DPM server on this WS.
    In the DPM Console I am able to connect to this Workstation successfully from the Administrative, Agent Space.

    The DPMClientProtectionCurr.errlog file shows this repeatedly:

    0FC0    065C    10/13   05:02:32.499  03        service.cpp(298)          [000000000021FD90]             ACTIVITY          CService::AnnounceServiceStatus

    0FC0    0D18    10/13   05:02:33.059  33        dlsclientprotection.cpp(778)            [00000000002BC850]             NORMAL           Connecting to DPM Server: (<Server.FQDN>)

    0FC0    0D18    10/13   05:02:33.171  33        dlsclientprotection.cpp(861)            [00000000002BC850]             WARNING         Failed: Hr: = [0x80004005] : Failed to set client OS details - ClientName:<WS.FQDN>, ClientOSVersion:6.1.7601, OSType:2, AgentVersion: 4.0.1920.0

    0FC0    0D18    10/13   05:02:33.171  33        dlsclientprotection.cpp(1490)            [00000000002BC850]             WARNING         Failed: Hr: = [0x80004005] : Failed to get connection to DPM server: lVal : ConnectToDPMServer(bstrClientMachineName, &pIUnknown, &fConnectionSuccessful, &dCurrentStatus, exceptionResult)

    The DPMRACurr.eerlog show this for both WS's:

    0EF0 1110 10/13 04:05:02.157 22 genericthreadpool.cpp(824) [000000000093C360]  NORMAL Hr: = [0x80070002] CGenericThreadPool::m_dwMaximumNumberOfThreads[20]
    0EF0 1110 10/13 04:05:02.157 03 miscellaneousutils.cpp(918)   NORMAL Error:ERROR_UNKNOWN_PRODUCT, While detecting DPM version. Assuming DPM isnt installed.

    And this one repeatedly:

    0BE8 08EC 10/13 13:59:40.404 29 radefaultsubtask.cpp(382) [00000000002F1640] 4F801526-72F2-4460-8760-F9D6E127FECB WARNING Failed: Hr: = [0x809909b0] : CRADefaultSubTask: WorkitemID does not exist, {DB3F138D-DE37-414D-BADC-5A161C6E7E1C}
    0BE8 08EC 10/13 13:59:40.404 05 defaultsubtask.cpp(546) [00000000002F1640] 4F801526-72F2-4460-8760-F9D6E127FECB WARNING Failed: Hr: = [0x809909b0] : Encountered Failure: : lVal : CommandReceivedSpecific(pCommand, pOvl)
    0BE8 08EC 10/13 13:59:40.404 05 defaultsubtask.cpp(751) [00000000002F1640] 4F801526-72F2-4460-8760-F9D6E127FECB WARNING Failed: Hr: = [0x809909b0] : Encountered Failure: : lVal : CommandReceived(pAgentOvl)

    The 2nd WS Process:

    I did not remove or touch the local agent installation because the information is populated on this client’s agent properties fields.
    I can see the folder selections I’ve chosen to be backed up by the protection group configuration.
    When i open the Agent UI I receive the sam DCOM error.
    I also receive a different error message on this WS when I try and do a Sync Now from the General Tab: Failed to trigger synchronization.

    I was able to perform a consistency check on this WS that completed successfully from the DPM server.
    I’ve validated the networking configuration settings are correct.
    I flushed local DNS cache.

    Thanks,

    Paul

    • Edited by Paul C. Johnson Saturday, October 13, 2012 8:05 PM More updated information
    Saturday, October 13, 2012 6:21 PM

All replies

  • I have identical problem. I have tried on a client remove group and reinstall manually agent but it doesn't resolve. It is occorred after last windows update with rollup 3 for dpm 2012 and I have done same actions of Paul C. Johnson.


    http://nicogis.blogspot.com


    Seems ru3: I have reinstall DPM 2012 without install ru3 and the agent client runs Ok.

    • Edited by nicogis Thursday, October 18, 2012 5:03 PM
    Sunday, October 14, 2012 10:33 AM
  • I have same problem after updating my server clients. I can't backup any of my vm's now.

    Anyone from MS want to respond?

    Thursday, October 25, 2012 9:03 PM
  • I was able to manually install agent to my Hyper-V hosts and set DPMServerName. Now it works.
    Thursday, October 25, 2012 9:23 PM
  • Manually updating agents and running "SetDpmServer -dpServerName XXX" was the first thing I tried.  It worked on one or two computers, but not on most of them.


    davery

    Thursday, October 25, 2012 9:41 PM
  • I'm seeing the same issue. Two Win 7 client machines where I've done a manual install of the agent followed by SetDPMServer are showing this issue. The machines where the agent was upgraded seem ok. Might have to open a support case for this - will report back if I find a solution.
    Tuesday, October 30, 2012 2:04 PM
  • I am having the same issue.  Some clients are syncronizing just fine while others throw this error.

    failed to connect to DPM server error:error HResult e_fail has been returned from a call to a com compenent

    Tried manual installs and setdpmserver commands without success.

    Tuesday, October 30, 2012 6:57 PM
  • I have also the same issue, but on all clients. All clients are Win7 64Bit.

    Please help.


    viktor

    Wednesday, October 31, 2012 6:51 AM
  • Ok - well it's looking like there are a few of us with this problem. Is everyone else seeing this only with Update Rollup 3? I can't find any other references to this specific problem apart from this thread so it looks to me like some kind of systematic problem introduced with UR3.

    Anyone from the DPM team able to comment on this?

    Thanks,

    Tim

    Wednesday, October 31, 2012 10:12 AM
  • I am having the same issue with a Windows 7 Client x64 only.  My 32bit ones are working as expected.
    Wednesday, October 31, 2012 12:56 PM
  • Hi

    I tried install SP1(Beta) for System center DPM . And now it is work. I have clear instalation of DPM Srv I could experiment!

    http://social.technet.microsoft.com/wiki/contents/articles/4058.list-of-build-numbers-for-system-center-data-protection-manager-dpm-en-us.aspx

    J.


    Jaja

    Wednesday, October 31, 2012 1:01 PM
  • Same problem for me with several Windows 7 x64 clients after rollup 3.  I dont want to install the SP1 Beta in a live environment as a fix though, does anyone know when the SP1 final is out?

    A

    Thursday, November 1, 2012 4:03 PM
  • Hi,

    I have a Windows 7 x64 machine that exhibits this problem. It seems that it is not caused on the client side but on the server side.

    In our case the server logs the following every time the client tries to connect:
    WARNING    Verify disconnected client failed with exception: System.ArgumentException: Das Element wurde bereits hinzugefügt. Schlüssel im Wörterbuch: "<machinename>". Hinzuzufügender Schlüssel: "<machinename>".
    (Translation: Element has already been added. Key in Table: "<machinename>". Key to be added: "<machinename>".

    I have uninstalled the agent on the client several times. One time I have seen the following error message on the server side:
    Deployment.cs(2815)            NORMAL    Removing all agent records for server[<machinename>] from table InstalledAgent.
    ntlmutils.cpp(185)            WARNING    Failed: Hr: = [0x80070002] : Error trying to open key [HKLM\Software\Microsoft\Microsoft Data Protection Manager\Agent\2.0\NtlmAuthData\<machinename>]
    SchedulerImpl.cs(166)            NORMAL    Entering DeRegister, JobDefID: bafe2b8b-53b2-4694-aa28-9e2c6c152d51
    Catalog.cs(1006)            WARNING    No retry on exception The specified @name ('') does not exist. while executing sp_delete_alert
    Catalog.cs(1013)            WARNING    SqlException encountered, SqlRetryCommand diag details - SqlCommandText  => Name=msdb.dbo.sp_delete_alert, CommandType=StoredProcedure
    Catalog.cs(1013)            WARNING    CommandDiagInfo => CanRetry=False, CommandTimeout=3600
    Catalog.cs(1013)            WARNING    CommandParams   => Count=2, InTx=True
    Catalog.cs(1013)            WARNING         Param[0]   => ParameterName=@name | Value= | Size=0 | DbType=NVarChar | Direction=Input | IsNullable=False
    Catalog.cs(1013)            WARNING         Param[1]   => ParameterName=@RETURN_VALUE | Value=1 | Size=0 | DbType=Int | Direction=ReturnValue | IsNullable=False
    EventManager.cs(98)            NORMAL    Publishing event from SchedulerImpl.cs(838): JobScheduleChange, [JobDefID=bafe2b8b-53b2-4694-aa28-9e2c6c152d51]

    Errors on the client side appear the moment the agent is re-added to the DPM server (I use "connect agent" instead of "install agent"). After that moment I get the message "Error connection to the DPM server. Error: a COM-component returned E_FAIL" every time I open the DPM client. This is mirrored by the Verify error mentioned above on the server side.

    To me it seems that parts of the machine config are still in the MSDB after removal (maybe caused by the registry error). If this client is connected again, the orphaned database entries cause the Verify error

    If that's true, how could we get rid of those entries? Would it help to rename the client?

    Uwe

    Thursday, November 1, 2012 5:14 PM
  • Hi,

    today I tried to confirm my assumption above. Since we have a second DPM 2012 server running U3 as well, I attached the client to the second server.
    Then I tried to create a protection group similar to the one on the first DPM server (where I removed this client from all protection groups and deleted the agent entry).
    During the creation of the protection group I got the message that "some or all of the datasources are already protected on the primary server". Then the configuration job for the client on the second server failed repeatedly.

    I believe this proves that there are orphaned record on the primary server that cause this trouble. I'm currently unable to protect this client which is not acceptable.

    I would really appreciate a comment from the DPM team regarding this issue (or some tip how to proceed).

    Thanks in advance.

    Uwe
    Friday, November 2, 2012 10:30 AM
  • Can you check this location on the client

     Microsoft Dataprotection Manager\DPM\Datasources

    Please check if this file is present - PSDATASOURCECONFIG.xml


    Tuesday, November 6, 2012 2:44 AM
  • Hi,

    thanks for the reply. Yes, this file is present, but you need to know the following:

    Since the machine in question is a desktop system, I've implemented a temporary workaround:
    I connected to the agent as a server. This allowed me to back up the necessary user files and it works without a problem.

    To me that proves again that the problem lies in the "disconnected client"-Tables on the server...

    Regards

    Uwe

    Tuesday, November 6, 2012 7:52 AM
  • Hi,

    I'm seeing the same log entry that Uwe is reporting :-

    WARNING Verify disconnected client failed with exception: System.ArgumentException: Item has already been added. Key in dictionary: '<machinename>'  Key being added: '<machinename>'.

    I wanted to test Uwe's theory that this was a stale record in the DPM database so I deleted that machine's entry in the tbl_AM_Server and tbl_CM_Server tables (and many cascading constraints). I then re-attached the client - it got a new GUID in the database, added it to a protection group and I'm still seeing the same errors.

    This is getting very frustrating. It seems like it's not possible to remove UR3 - can anyone advise if it would be possible to backup the database, uninstall DPM, reinstall it without UR3 and restore the database - i.e. does UR3 introduce any schema changes?

    Tim

    Tuesday, November 6, 2012 3:47 PM
  • That file is present on my clients also.

    I have been backing up from the server with no errors, however, I still cannot access the client tools from the desktop.

    don


    davery

    Tuesday, November 6, 2012 6:38 PM
  • Hi,

    I have the same problem ? Some other sugestions ?

    Carlos.


    Carlos dos Santos
    blog: www.carloscds.net 
    twitter: @cdssoftware

    Thursday, November 8, 2012 4:44 PM
  • Hello,

    It"s true i have same problem from update RU3.

    some clients have update 4.0.1908.0 to 4.0.1920.0 (XP or Windows 7) work's fine, but all new client were install 4.0.1920.0 or downgrade to 4.0.1908.0 not work now.

    it"s very big problem for VIP workstation

    All server work with this vers 4.0.1920.0

    Sunday, November 11, 2012 4:42 PM
  • Hi,

    I had the exact same issue with some but not all clients after updating

    I resolved it on one Win7 x64 machine by removing the DPM client from the workstation, removing the client from the DPM server - Then rename the workstation and reinstall the DPM client on the workstation from the DPM server. Renaming the workstation seems to have done the trick

    Looks like the issue is with the server not the client - during testing I removed the dpm client from the workstation and reinstalled it from the server it opened fine and did not give the error until I added the workstation to a protection group at which point it threw up the error.

    Hope this helps someone. 

    Friday, November 16, 2012 3:26 PM
  • We have detected exactly the same problem in our DPM environment after UR3 installation via Windows Update.

    But, looking into update history list on  app server I have noticed that Update Rollup 3 has been marked with status Failed even though installation process hadn't been interrupted or notified of any potential problem. It's been suggested in the message that restart might help, but status Failed remained the same after the reboot.

    Do you find this similar to your system? Has anyone made to  uninstall the update yet? 

     

     

    Tuesday, November 20, 2012 3:45 PM
  • Same here. The client log says:

    o DPM server: lVal : ConnectToDPMServer(bstrClientMachineName, &pIUnknown, &fConnectionSuccessful, &dCurrentStatus, exceptionResult)
    1BE8 09C8 11/22 04:38:00.159 33 dlsclientprotection.cpp(778) [00000000001574F0] NORMAL Connecting to DPM Server: (Server)
    1BE8 09C8 11/22 04:38:00.190 33 dlsclientprotection.cpp(861) [00000000001574F0] WARNING Failed: Hr: = [0x80004005] : Failed to set client OS details - ClientName:client, ClientOSVersion:6.1.7601, OSType:2, AgentVersion: 4.0.1915.0
    1BE8 09C8 11/22 04:38:00.190 33 dlsclientprotection.cpp(240) [00000000001574F0] WARNING Failed: Hr: = [0x80004005] : Failed to get connection to DPM server: lVal : ConnectToDPMServer(bstrClientMachineName, &pIUnknown, &fConnectionSuccessful, &dCurrentStatus, exceptionResult)

    This is once the DPM client is updated from 4.0.1950 (Update tollup 2) to 4.0.1920 (Update rollup 3)

    Opening the DPM client from the system tray results in the 

    HRESULT E_FAIL...DCOM

    This is a rather serious problem :(

    Thursday, November 22, 2012 5:31 AM
  • This is a rather serious problem :(

    This is a serious problem. Frankly I'm astonished by the lack of response from Microsoft. This is a repeatable problem being reported by many. This thread has had 1400 views suggesting many others have this issue. It's clearly a bug. The only workaround is renaming machines, something that just isn't viable for many of us.

    Surely people in this thread have done enough to pinpoint the issue and allow MS to develop a fix? Even a statement saying yes, we knowledge the issue and are working on it would be helpful, but just silence! It's just incredible that a patch that breaks an enterprise product isn't treated with more urgency.

    What are we supposed to do, cross our fingers a patch will come out soon? 

    Thursday, November 22, 2012 1:13 PM
  • Has anyone made to  uninstall the update yet? 

    Unfortunately it's not possible to uninstall the update It's only possible to uninstall and re-install the entire server. Whether it's possible / safe to backup the database from UR3 and restore to UR2 is unknown. Don't fancy risking it myself.

    Thursday, November 22, 2012 1:17 PM
  • Can you check if the CU 3 update is successfully completed. You can view that in the Control Panel -> System and Security -> Windows Update -> View Update History.

    If the status shows as failed, see if you can reinstall CU3 on DPM server and then try reinstalling agent on the client.

    Regards,
    Gangs-MSFT


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Gangs

    Thursday, November 22, 2012 6:02 PM
  • The CU3 update was successfully installed on the DPM server. The problem on some client's is still there. 

    Rename the client computer is not a solution for us. We have completely removed the client from all protection groups and delete the agent entry, but it seems, that there are still orphaned records in the database.

    Friday, November 23, 2012 9:53 AM
  • Hi Bjorn,

    Thats exactly what we did and came to the same conclusion - ophaned records in the database

    Our only soloution after completly removing it was to rename the machine which luckily we could but I agree is not really viable workaround.

    Ian 

    Friday, November 23, 2012 9:59 AM
  • Same problem here. Some agent Win7 x64 with RU3 client cannot be protected. When opening client it says HRESULT ... No mather what I do i keep geting into this error.

    Renaming an workstation is not an option for me.

    Thursday, November 29, 2012 11:40 AM
  • This is unacceptable.  Does anyone know the release date of SP1? 

    I've been using DPM since the 2006 version and I've had constant issues through each version.  When it comes to backup the solution has to work and I will be looking elsewhere next year if this isnt fixed very soon!

    Thursday, November 29, 2012 4:01 PM
  • We have had a support ticket open with Microsoft for 28 days now on this problem and are no closer a solution than we were at day 1!

    Unfortunately because DCOM reports the error they believe the problem is that the client can't communicate with the server, this is incorrect the client can quite happily communicate with the server, however the server then errors which the client reports as an error during DCOM.

    As others have mentioned above, the issue appears to be that when the client attempts to talk to the server, the server errors with...

    Verify disconnected client failed with exception: System.ArgumentException: Item has already been added. Key in dictionary: 'ABCD.LMP.LOCAL'  Key being added: 'ABCD.LMP.LOCAL'

    This results in the client not being able to initialize and hence no backups are possible.

    This error appears in the client logs as...

    NORMAL Connecting to DPM Server: (DPM-SERVER.LMP.LOCAL)
    WARNING Failed: Hr: = [0x80004005] : Failed to set client OS details - ClientName:ABCD.LMP.LOCAL, ClientOSVersion:6.1.7601,
                                                               OSType:2, AgentVersion: 4.0.1920.0
    WARNING Failed: Hr: = [0x80004005] : Failed to get connection to DPM server: lVal : ConnectToDPMServer(bstrClientMachineName,
                                                               &pIUnknown, &fConnectionSuccessful, &dCurrentStatus, exceptionResult)

    I have to say I'm very disappointed with the percieved lack of effort from Microsoft to solve this problem which was caused by a Microsoft supplied update to an Enterprise product.

    Friday, November 30, 2012 8:51 AM
  • HEY MICROSOFT - ARE YOU LISTENING TO US???

    This is getting really frustrating!! You can't issue an update which breaks a core infrastructure system and then go silent, that is really shabby! We need some answers! People are going to end up losing data as some client machines will not have not been backed up for weeks due to this issue. I'm now in the very awkward position that I have to tell half my laptop users that backups are down until further notice and there is no plan for fixing them.

    Is the DPM development team aware of this issue? This is a bug, first line support can't help, it needs immediate escalation to the developers.

    Have they pinpointed the cause?

    Are they working on a fix / what timescale?

    Are there any viable workarounds? e.g. SQL Script to patch up problems in the database; Is it safe to uninstall UR3, re-install a prior version and recover the database? Will you support an upgrade from SP1 beta to RTM for those affected by this problem?

    Is there anything we can do to help?

    Friday, November 30, 2012 9:59 AM
  • I was able to totally destroy the DPM 2012 server used to back up clients.

    I created a new server with a different name and IP number - new database.

    I installed agents on  5 test systems at version 1908. - all worked well.  This included three machines that have always worked no matter what i did - three hand loaded machines - Windows 7 x386, Windows 7 x64 and a Windows 8 machine with the fixup registry hack.  Two of the five machines did not work since October 17 but they work now.

    I installed the Rollup 3 with the WSUS - Windows Update - I updated the 5 agents - all went well.

    Then...

    I pushed some clients from the DPM Console and set up protection.

    I also, due to mental exhaustion, decided to just protect all 400 clients and then have a GP logon script cause the installation of the agents with the server name included when people log on.  All the agents show up in the protection groups and in the agents list.

    I probably got two agents actually functioning with a backup - in addition to the original 8 test agents.

    I can see DCOM errors in the SYSTEM LOG but I believe these are caused by DPM trying to contact agents off the network.

    I monitor the DPM network activity with WIRESHARK.  I see lots of network traffic with various agents chatting with the server.  I can see the traffic of the few agents that are working.

    It is difficult for me to beleive this is a SQL Database issues since I have a brand new database.  It is as though I have lost the agents and cannot ever get them back.  They take the 1920 install and know the name of their DPM server.  They are in the Trusted Server groups in DCOM.  In desperation I added authenticated Users for the DPM Server in the DCOM Admin Tool since that seemed to make a difference once in the past.

    In summary, I have seen everything above since Paul Johnson's original post.  I am concerned it is some sort of identity issue - not even DPM related at all - guids, sids, certificates or perhaps something caused by using GHOST to image the machines.

     

    Friday, November 30, 2012 3:08 PM
  • We are looking into this now and will update soon.  Thanks for your patience.

    Travis Wright, Principal Program Manager, Microsoft

    Monday, December 3, 2012 8:08 PM
  • Nothing yet??
    Wednesday, December 12, 2012 7:22 PM
  • We have support case open at MS and this is the last info from Support:

    "This looks like a bug. I had one more case with identical behavior. PG did not yet closed it as a bug and did not find a solution to it but this has been already escalated to Escalation Engineer and we colected all the logs Product Group wanted from us so now we are just waiting for PG updated .."

    Bostjan 
     

    Thursday, December 13, 2012 7:26 AM
  • 35 days after raising a case, support confirmed it as a bug and re-stated the workaround was to rename the affected machines.

    Unfortunately we have lost all confidence in the support for the product so have made alternate arrangements for our server & workstation backups.

    I'm glad we didn't follow supports advice a few weeks ago and install SP1 beta as it as now been announced there is no upgrade route to release SP1.

    Thursday, December 13, 2012 10:28 AM
  • Hey guys, just a quick update from MS Support case:

    The only known workaround so far is to rename the problematic workstation. You can rename and leave workstation with new name, or you can rename into new name and then rename back to original name (client1 -> test1 -> client1). Tested both scenarios and I was successful on both ! Just be sure to rename either all small letters or capital letters (don't mix).

    Bostjan

    • Proposed as answer by Nexustk Wednesday, December 19, 2012 3:35 PM
    Friday, December 14, 2012 5:21 AM
  • I have same problem.

    client Windows 7 x64 professional.

    Any news?

    Thursday, December 20, 2012 2:22 PM
  • I'm curious what changes that allows the computer to connect after being renamed and then renamed back.
    • Edited by Maphisto1 Thursday, December 20, 2012 6:41 PM
    Thursday, December 20, 2012 6:40 PM
  • Berglez: Your solution worked for me!!!

    We just started testing DPM. Brand new install of DPM2012. Installed Roll-up 3. Used DPM server to push client to test workstation. Created Protection Group. Client could not connect to server - generated errors as show at the top of this thread.

    Simply renamed workstation, rebooted, named back to original name, rebooted, and everything worked fine.

    It's definitely a hack - but it's a simple process and it works.   It'll hold us over for testing purposes until Microsoft resolves root cause..

    Thanks!

    • Edited by _tv_ Thursday, December 27, 2012 7:51 PM formatting problems
    Thursday, December 27, 2012 7:50 PM
  • Berglez: Your solution worked for me also!!!

    I renamed the workstation, rebooted, renamed again, rebooted an now it's works!

    Thanks.

    • Proposed as answer by ChrisStyle Sunday, January 6, 2013 2:04 PM
    Friday, December 28, 2012 5:26 PM
  • yes solution approved,

    1 rename Client Workstation Error in dcom

    2 Add client to DPM and Protected group

    3 as you want delete old client machine from protected group and keep old datas

    4 use script dpm remove-productionserver

    Sunday, January 6, 2013 2:05 PM
  • I notice this has been nominated as an answer. Forgive me - but renaming machine really is NOT an answer - it's a crude workaround and one that's impractical for large deployments. 

    The only true answer will be when Microsoft roll out a fix for this bug which their update introduced!

    I will be testing DPM 2012 SP1 RTM shortly and will report back if this has resolved the issue.

    Tim

    Monday, January 7, 2013 9:50 AM
  • I just migrated our company to DPM2012 from DPM2010. Basically I just built a new DPM server and pointed everything to the new box. 

    Most servers moved over without a hitch (9 servers out of 12). 

    I had the issue with a Win2k3R2 server running mainly IIS. I ended up uninstalling the agent and then deleting the directory under 'Program Files' as there were some files left in there from the 2010 version. Rebooted and installed the DPM2012 agent again and the machine now works.

    Now I'm left with the problem on two Win2k8R2 AD servers. Renaming is not an option that I can pursue. I can back these up by other means for now.

    Watching this thread closely.

    Warren

    Monday, January 7, 2013 3:02 PM
  • I think this has been fixed.

    I noticed in the pending updates form this months patch Tuesday "Update Rollup 1 for System Center 2012 Service Pack 1" kb2785682. This fixes one issue with DPM "Client backups fail when there is a case difference between the client computer name on the computer and the client computer name that is stored in Active Directory." My problem clients did indeed have a case mismatch - all machine names in AD seem to be uppercase. I'm speculating that it might be machines that have been re-installed and joined to existing domain accounts where this mismatch has occurred.

    This explains why the fix of renaming and naming back the clients works - it's gets the cases consistent again.

    Last week when I downloaded SP1 RTM it seemed to only be available on Technet - not sure if it's generally available yet. Installing SP1 itself did not resolve the issue, but installing update rollup 1 has.

    Anyway, three months after the start of this thread we finally know the root cause and have a fix. Unfortunate for those who need to do rigorous testing before deploying a service pack, but hopefully knowing the root cause will help.

    Delighted this is sorted for me - good luck everyone else!

    Wednesday, January 9, 2013 3:26 PM
  • Just a caution to anyone considering applying SP1 UR1 - this has left my servers reporting different version numbers in different places and the newer remote agent not present in the ProtectionAgents folder. Although the update doesn't report an error on installation I'm a little concerned that the update may not have applied completely. 

    Not wanting to drag this thread off topic I've started a new thread on this issue which you may wish to check.

    Tim

    Thursday, January 10, 2013 10:54 AM
  • I confirm: sp1 doesn't resolved the problem but I am downloading sp1 ur1 (kb2785682) but now it's missing: peraphs are working to fix of sp1 ur1 (see note of Tim)?

    http://nicogis.blogspot.com


    • Edited by nicogis Wednesday, January 23, 2013 5:05 PM
    Wednesday, January 23, 2013 5:04 PM
  • DPM SP1 UR1 (version 4.1.3333.0)  from windows update resolve the problem!


    http://nicogis.blogspot.com

    Friday, January 25, 2013 10:05 AM
  • Yes,  they seem to have sneaked out a DPM 2012 SP1 UR1 (v2) on KB2802095 which takes it to version number 4.1.333.0. Download here.

    This resolves the issue I saw with the inconsistent version numbers and also seems to have resolved the original DCOM error.

    Three months to fix a patch which broke a critical enterprise product! 

    • Proposed as answer by TimBoothby Friday, January 25, 2013 10:54 AM
    Friday, January 25, 2013 10:54 AM
  • The log file: c:\Program Files\Microsoft Data Protection Manager\DPM\Temp\DPMClientProtectionCurr.errlog

    Contained the error: Failed to set client OS details - ClientName:xxx.contoso.com

    In Active Directory, the dNSHostName attribute of this computer was uppercase, XXX.contoso.com. I changed the dNSHostName in AD to match the name that DPM was trying in the logfile, and it seems to have solved the issue. There was no need to rename the computer.

    Tuesday, May 6, 2014 9:01 AM