I am doing a test recovery of a Windows Networker Client. I build the windows 2003 R2 SP2 using the same updates and patches it had before the disaster. Installed NW 7.6 and started to do a recovery following the NW DR guide. According to the guide, I was supposed to only restore the "SYSTEM" savesets first. This includes all "VSS SYSTEM ..." savesets also.
After restoring the savesets, I was asked to reboot the server, which I did. After the reboot, I saw the errror below and the server is in an endless loop.
LSASS.exe When trying to update a password the return status indicates that the value provided as the current password is not correct.
Has anyone seen this problem or know what might be the solution. I suspect LSASS.exe is a Windows protected file and the restore has some issue in recoverying that file. I also have to mention that when building the server, the Administrator account was called "Administrator" and the password was 12345. Before the disaster, the Administractor account was called SysAdmin and the password was 67890. Should I have done anything with the Administrator account and password when I was building the server?
Password itself does not matter here (see some MS articles - it seems to be more as registry corruption issue), but admin account name might if renamed. Did you try this with same admin account as on old machine?
I am also doing a disaster recovery test of a Windows 2003 SP2 (not R2) server and experiencing exactly the same error. The backup was created with 7.6 build 142, and the restore is being attempted with the latest 188.8.131.52 release of the client. The networker server is also running 184.108.40.206. I can confirm that the local admin password was set exactly the same as on the production server.
The exact error message is: "lsass.exe - System Error - When trying to update a password, this return status indicates that the valude provided as the current password is not correct."
This error message occurs after initiating the reboot following the restore of the VSS save sets and results in continuous reboots of the server until I power off the VM.
I also noted the following error in the recovery log:
17474:winworkr: Preparing for VSS SYSTEM BOOT recover, please wait...
. The system continually reboots with the same error over and over again.
Help from this community would very much be appreciated - however I will likely log an SR as this is a critical situation for us.
Thanks in advance.
Thanks for your quick response Mike. Unfortunately that solution seems to relate to XP, and I am dealing with Windows Server 2003 SP2, though I am aware of the simularities.
I'm also a little confused. Does this imply that my production server has a corruption which got transferred to my backup tapes? Or is there a problem with my newly rebuilt server? The only credentials which exist on the new server is that of local administrator. Prior to attempting the restore, I can log in to either server with those credentials and the same password without encoutering an error.
I will reread the article again and see if I missed the details - I may be over reacting slightly out of frustration as I have wasted my entire day trying to get this restore done. I'm just thankful I created a snapshot of the system before attempting the restore. Makes starting over a lot easier.
Thanks again for your response. Please feel free to expand if you think of anything.
The issue is not specifically XP or W2K3. The issue is with LSASS which is a MS security module.
Local Security Authority Subsystem Service (LSASS), is a process in Microsoft Windows operating systems that is responsible for enforcing the security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens. It also writes to the Windows Security Log.
Forcible termination of lsass.exe will result in the Welcome screen losing its accounts, prompting a restart of the machine.
One question would then be was the server rebuilt with the same W2K3 media. i.e. OEM vs Retail or MSDN.
The MS article will be of help but it will be more what was different with the current deployment.
i read your article and facing the same problem.
I noticed that my recover is performed on a machine with a different license type, is it an EMC prerequise ?
EMC support told us to upgrade or version from 75.3.1 to 220.127.116.11 but with no success.
Thanks for your feedback
Did you get any answer or solution on this? I have got exactly the same problem today when I did a DR test on one of our virtual servers. I am very curious to know if you managed to get the server running again.