Hi all, We are getting an error on one of our TSM clients that does not want to back up the ASR information.
Client OS: Windows Server 2003 R2 Enterprise x64 Edition Service Pack 1 Client TSM: 5.3.4.0 Error in dsmerror.log 12/10/2007 21:54:30 ANS1228E Sending of object 'C:' failed 12/10/2007 21:54:30 ANS1468E Backing up Automated System Recovery (ASR) files failed. No files will be backed up. To figure out what was going on, I enabled tracing with the DIROPS and FILEOPS flags. From that, I gathered there was a problem with creating either files or directories, this is from the end of the tracelog: 12/11/2007 13:39:00.691 : psfsinfo.cpp (1566): fioStatFS(): GetVolumeInformation: RC=21 12/11/2007 13:39:00.691 : psfsinfo.cpp (1567): fioStatFS(): Invalid File system 12/11/2007 13:39:00.691 : ntfileio.cpp (5212): CreateDirectory(): Win32 RC=183 . 12/11/2007 13:39:00.691 : ntfileio.cpp (5212): CreateDirectory(): Win32 RC=183 . 12/11/2007 13:39:00.691 : ntfileio.cpp (5212): CreateDirectory(): Win32 RC=183 . 12/11/2007 13:39:00.691 : psbackup.cpp ( 953): psPrepareObjectForBackup(): processAsr(): RC = 4655 I decided to check the ADSM.SYS directory on the machine, and noticed an ASR folder. I removed that folder, and the result of the trace is slightly different: 12/11/2007 13:40:59.112 : psfsinfo.cpp (1566): fioStatFS(): GetVolumeInformation: RC=21 12/11/2007 13:40:59.112 : psfsinfo.cpp (1567): fioStatFS(): Invalid File system 12/11/2007 13:40:59.112 : ntfileio.cpp (5212): CreateDirectory(): Win32 RC=183 . 12/11/2007 13:40:59.112 : ntfileio.cpp (5212): CreateDirectory(): Win32 RC=183 . 12/11/2007 13:40:59.112 : psbackup.cpp ( 953): psPrepareObjectForBackup(): processAsr(): RC = 4655 There is one less error with RC 183, and the ASR directory is created in ADSM.SYS. I did some searching and concluded that RC 21 means *ERROR_NOT_READY 21 0x15* *The device is not ready.* while RC 183 means *ERROR_ALREADY_EXISTS 183 0xB7* *Cannot create a file when that file already exists.* Now, RC=21 is followed by 'Invalid File System', while the directory can be created but not the contents that should be there. Even while that directory is empty. I already checked the permissions, and just to be sure I reset the permissions on all subfolders of ADSM.SYS to match the permissions of ADSM.SYS. This did not help, as you probably gathered. I even noticed that, when I made sure all permissions would be inherited on subfolders of ADSM.SYS, the ASR folder that was created, did not inherit the permissions. Could that be the root of the problem? Or is at a 32-bit vs. 64-bit issue? The OS is 64-bit, but I'm not sure if the TSM client is. I cannot find that information, and the tracing does mention Win32, and not Win64 (but it might as well always say Win32, regardless of the version). Any pointers are appreciated; are there any more traceflags I could enable to find the reason for this error? Kind regards, Rick Harderwijk
