Fewer files inspected after 5.5 client upgrade?

[12ozProphets]

We upgraded a Windows Server 2003 x64 machine from 5.4.1 to 5.5.0. We wanted to test x64 Open File Support which was not available on x64 5.4.1. This server is not used in production and the only changes to it was the 5.5 upgrade.

On 5.4.1 my dsmsched.log shows:
01/28/2008 22:01:59 Total number of objects inspected: 23,469

After upgrade to 5.5.0 dsmsched.log shows:
01/29/2008 22:01:34 Total number of objects inspected: 17,414

The include/exclude options did not change, and there are no errors in the dsmerror.log.

I'm still looking into this but has anyone else seen this?
Thanks!

 

[12ozProphets]

Ok, after doing some reading it seems that some files that were included by default in the backup of the C: drive are now part of the "system state". This explains the count difference.

Thanks!
--bill

 

[Elomis]

Six thousand of them?

Are you SURE?

 

[12ozProphets]

I went through the dsmsched.log line by line. There is nothing missing. All changed files are backed up.

But you are right. It does make me worry. If someone could confirm this it would be great!

 

[12ozProphets]

Almost forgot!

I also loaded 5.5 on 2 more servers. Same results. About 6000 files less are inspected on each server.... But as far as what is backed up. It looks to me like it got everything...

 

[12ozProphets]

Something else I noticed. A scheduled backup runs with no errors, but if I do an incremental from dsmc I get errors. Does anyone know why there is a difference? Sorry, we are new to tsm! (It still shows 6000 less files inspected)

Here are the errors. I'm going to try to track these down today.

01/31/2008 08:06:39 ANS1228E Sending of object 'C:' failed
01/31/2008 08:06:39 ANS1468E Backing up Automated System Recovery (ASR) files failed. No files will be backed up.
01/31/2008 08:06:52 ANS5250E An unexpected error was encountered.
TSM function name : NTSecurityReadV2
TSM function : CreateFile() returned '5' for file '\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy37\WINDOWS\Temp\hsperfdata_SYSTEM\1288'
TSM return code : 106
TSM file : ntsecurity.cpp (969)
01/31/2008 08:06:52 ANS1228E Sending of object '\\qas\c$\WINDOWS\Temp\hsperfdata_SYSTEM\1288' failed
01/31/2008 08:06:52 ANS4007E Error processing '\\qas\c$\WINDOWS\Temp\hsperfdata_SYSTEM\1288': access to the object is denied
01/31/2008 08:06:52 ANS1802E Incremental backup of '\\qas\c$' finished with 1 failure

 

[12ozProphets]

I have this one figured out. The "access denied" errors are due to a problem with the "backup files and directories" Windows Group Policy.

A all other problems were fixed by going to 5.5.0.2.

 

[el.b00ty]

I have this one figured out. The "access denied" errors are due to a problem with the "backup files and directories" Windows Group Policy.

A all other problems were fixed by going to 5.5.0.2.

Can you elaborate on this? I'm having a similar error on one of my servers where, even though the DFSroot share is excluded in dsm.opt, it's still trying to back it up and is reporting errors...


TSM function name : NTSecurityReadV2
TSM function : CreateFile() returned '1232' for file 'D:\DFSRootShare\HR'
TSM return code : 106
TSM file : ntsecurity.cpp (969)
04/13/2008 21:36:58 ANS1228E Sending of object \\server\d$\DFSRootShare\HQMarketing' failed
04/13/2008 21:36:58 ANS4007E Error processing '\\server\d$\DFSRootShare\HQMarketing': access to the object is denied
04/13/2008 21:36:58 ANS5250E An unexpected error was encountered.

 

[12ozProphets]

Our problem was do to the Microsoft Windows Active Directory user account that I was starting the tsm client service under. I that user account the "backup files and directories" rights and then all was good.

--bill

 

[el.b00ty]

Maybe that's part of our problem... the TSM scheduler is configured to use the local system account. However, the servers I'm having a problem on are Domain Controllers, so... I guess I don't know where I'd go to check the rights on the system account.

Maybe I should have the scheduler running using a different account...?

 

[12ozProphets]

On a windows server go to start->admin tools->domain security policy

then go to security settings-> local policies->user rights assignment.

You can also control this at the domain account level on your windows domain controller from: start->admin tools->Active directory users and computers. Then select the OU (org unit), right click and choose properties. Then select the "group policy" tab. Then edit an existing policy or create a new one just as you would above.

hope this helps,
--bill