Hi,
I'm seeing an odd problem on the TSM server I look after.
The server manages around 250 Windows and Linux clients.
When I run
When I run
- every single one of the 200+ damaged files, across 50 different client nodes is a file called "LSASRV.MOF"
An example file:
\WINDOWS\WINSXS\AMD64_MICROSOFT-WINDOWS-LSA-MOF_31BF3856AD364E35_10.0.14393.0_NONE_2843A530B7F9FD68\LSASRV.MOF
So - all 200+ damaged files are on Windows nodes of varying OS levels, and every file is the same, with the exception that they are in a few different(but similar) locations.
Note: This issue appeared fairly soon (a couple of hours) after a repair storagepool command was run.
The repair command was:
It repaired 1 damaged file(which was the only damaged file showing in TSM at that time), and queries on the storage pool after the repair initially showed 0 damaged files.
Prior to running the repair, we had run an audit on the storage pool, which took about 4 days to run, so don't really want to start an audit again now if there is a better option, or some other investigation which can be tried first.
It seems it must be something about the file itself, rather than actual damage in TSM, given there is not a single other type of file being reported as damaged.
Has anyone had a similar problem with Windows files in TSM? Any suggestions on what could be causing this? Anything else I should be looking at?
TIA
I'm seeing an odd problem on the TSM server I look after.
The server manages around 250 Windows and Linux clients.
When I run
q damaged <STGPOOLNAME> type=node
it shows over 200 damaged files, across 50 nodes.When I run
q damaged <STGPOOLNAME> type=inventory
it shows something interesting: - every single one of the 200+ damaged files, across 50 different client nodes is a file called "LSASRV.MOF"
An example file:
\WINDOWS\WINSXS\AMD64_MICROSOFT-WINDOWS-LSA-MOF_31BF3856AD364E35_10.0.14393.0_NONE_2843A530B7F9FD68\LSASRV.MOF
So - all 200+ damaged files are on Windows nodes of varying OS levels, and every file is the same, with the exception that they are in a few different(but similar) locations.
Note: This issue appeared fairly soon (a couple of hours) after a repair storagepool command was run.
The repair command was:
repair stgpool <STGPOOLNAME> srclocation=replserver
, and appeared to be 100% successful.It repaired 1 damaged file(which was the only damaged file showing in TSM at that time), and queries on the storage pool after the repair initially showed 0 damaged files.
Prior to running the repair, we had run an audit on the storage pool, which took about 4 days to run, so don't really want to start an audit again now if there is a better option, or some other investigation which can be tried first.
It seems it must be something about the file itself, rather than actual damage in TSM, given there is not a single other type of file being reported as damaged.
Has anyone had a similar problem with Windows files in TSM? Any suggestions on what could be causing this? Anything else I should be looking at?
TIA