none
Having to re-run update-nondomainserverinfo.ps1 after DPM server reboot RRS feed

  • Question

  • Yesterday one of our DPM servers decided it didn't want to respond to stimulous anymore, so we gave it a kick last night and all was good in the world again (I'm not sure what caused the crash but it doesn't appear to have been DPM related). Checking the backup status I found that a number of the protection group members were displaying "Agent not reachable", and "Error" in agents management. (DPM Error ID 316, Internal error code 0x8099090E).

    Now all of the protected servers showing this are untrusted workgroup machines, and when I've seen this behaviour in the past it has been due to the password on the protected server being out of date, so I checked that, nope that was fine. On a hunch I re-ran :

    setdpmserver -dpmservername <our dpm server> -isnondomainserver -updatepassword

    and entered the password when prompted. I then re-ran update-nondomainserverinfo.ps1 on the DPM server, and sure enough the errors went away.

    Just to see if it would work I then tried just running update-nondomainserverinfo.ps1 against another one of the servers showing the error, and sure enough that one then worked as well.

    So I was wondering, does anyone know why this would be happening. Obviously it's not a major problem since I know how to resolve it if it happens again in the future, but I'd like to know why it happens in the first place. It almost seems as if the DPM server loses track of the protected servers details and needs reminding, yet when I check the security log on the protected server I can see that not only is the DPM server connecting to it, it is successfully authenticating using the same credentials that I've just had to re-enter.

    Wednesday, August 3, 2011 3:42 PM

Answers

  • Hi Marc,

    Sorry for the delay in responding. I did actually get to the bottom of this in the end, and it turned out to be related to the password expiration of the local accounts on the DPM server.

    I already knew that when in a workgroup setup we had a local login account on each protection server, and the DPM server would then connect to the protection server using those credentials. We'd already discovered that while DPM automatically creates the user on the protection server, the default account settings are left in place, eg expire after x many days. We'd previously discovered this and updated the accounts to no longer expire.

    Now what we didn't realise was that the DPM server also has an identical local account configured on it (in our case one for each protection server), which also have those same default password expiration settings to require the user to change the password on next login.

    So, the first time this happened we spotted the issue on the protection servers, ran the commands above and that resolved the issue. Those commands obviously reset the local passwords (which we knew about) and also the passwords on the DPM server (which we didn't know about). This time however, only the server had the issue with passwords, which is why we only needed to run the update-nondomainserverinfo.ps1 command. The fact that it happened immediately after the server crash confused me at the time, but of course until the crash / reboot happened there wouldn't have been another "login" to require the password to be changed, which is also why they all failed at the same time.

    Keith

    Monday, August 15, 2011 3:44 PM

All replies

  • Hi,

    Perhaps it is not related to credientials, but an issue with Windows Firewall losing its exceptions for the DPM agent communications. The errors you are seeing tend to be network communications related rather than permissions. Maybe try stopping the Base Filter Engine next time it happens (net stop BFE) and see if the DPM agent communication returns.

     

    Thanks,

    Marc

    Monday, August 8, 2011 3:08 PM
    Moderator
  • Hi Marc,

    Sorry for the delay in responding. I did actually get to the bottom of this in the end, and it turned out to be related to the password expiration of the local accounts on the DPM server.

    I already knew that when in a workgroup setup we had a local login account on each protection server, and the DPM server would then connect to the protection server using those credentials. We'd already discovered that while DPM automatically creates the user on the protection server, the default account settings are left in place, eg expire after x many days. We'd previously discovered this and updated the accounts to no longer expire.

    Now what we didn't realise was that the DPM server also has an identical local account configured on it (in our case one for each protection server), which also have those same default password expiration settings to require the user to change the password on next login.

    So, the first time this happened we spotted the issue on the protection servers, ran the commands above and that resolved the issue. Those commands obviously reset the local passwords (which we knew about) and also the passwords on the DPM server (which we didn't know about). This time however, only the server had the issue with passwords, which is why we only needed to run the update-nondomainserverinfo.ps1 command. The fact that it happened immediately after the server crash confused me at the time, but of course until the crash / reboot happened there wouldn't have been another "login" to require the password to be changed, which is also why they all failed at the same time.

    Keith

    Monday, August 15, 2011 3:44 PM
  • Thank you, thank you, thank you!

    Of course I set accounts in protected server to "Password never expires" but I haven't a clue that DPM server have same local accounts!


    Jako
    Monday, January 16, 2012 10:24 AM
  • Thank you also, i have been dealing with this for a year and never even thought to look at the DPM server local accounts.

    Much thanks!

    Brian

    Wednesday, May 16, 2012 1:55 PM
  • Keith,

    Since I was aware of the issue, I always ticked the box “Password never expires” on the AGENT SIDE (the protected server).

    As I remember, that was sufficient for DPM 2010.

    Now, while using DPM 2012 SP1, I had approximately each month a problem that the agent could not be reached.

    I could solve the issue with the .\Update-NonDomainServerInfo.ps1 command.

    However, after about a month, same problem reappeared.

    After reading your solution, I saw that on the DPM side, the box “Password never expires” also has to be checked.

    Thanks!


    JanV

    • Proposed as answer by Noah Stahl Thursday, March 26, 2015 3:59 PM
    Tuesday, June 25, 2013 8:58 AM