SCCM 2007 SP2-R2 OSD with Dell Backup and Recovery Manager 1.3

Will the program install successfully as a standalone software distribution? I'm trying to see if the command line doesn't work silently in general or if the issue is TS specific. The 8004005 error is "Access Denied" so something can't get to what it wants (writing a log file, etc.)

Thanks for the reply Warren,
I am writing the log to C:\windows\temp, as with the other installs in this TS, and they are getting written, so I don't think that is the problem. I have not tried advertising it as a software distribution to see if that works... I can give that a try. If I log into a Win7 system with an admin account and use the command line above (with the install files locally or on a network share), it does install perfectly and silently. Also the source directory for the package is in a share with all other application sources in our DSL, so the SCCM server has access... but you just made me think of something to check. I unpacked the msi on an XP work station and then copied it to the network share.. I wonder if the file access may be blocked due to copying from the workstation in question. I will check that.
jb

Nope, there were no file locks and inheritance was not blocked down to the .msi file, so all looks good there. Here is a snip from the smsts.log... can't put it all in

Successfully submitted event to the Status Agent. InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
End TS policy evaluation InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
Policy evaluation initiated InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
Waiting for policy to be compiled in 'root\ccm\policy\machine' namespace InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
Query path = 'CCM_SoftwareDistribution.ADV_AdvertisementID="XXX20034",PRG_ProgramID="Silentx64_norestart_TS",PKG_PackageID="XXX000CA"' InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
Verified policy is compiled in 'root\ccm\policy\machine' namespace InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
content location count = 1 InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
Invoking Execution Manager to install software InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
FALSE, HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\installsoftware\installsoftware.cpp,282) InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
Failed to invoke Execution Manager to Install Software for PackageID='XXX000CA' ProgramID='Silentx64_norestart_TS' AdvertID='XXX20034' hr=0x80004005 InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
InstallSoftware failed, hr=0x80004005 InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
0, HRESULT=80004005 (e:\nts_sms_fre\sms\client\osdeployment\installsoftware\installsoftware.cpp,746) InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)
Entering ReleaseSource() for D:\_SMSTaskSequence\Packages\XXX000CA InstallSoftware 7/28/2011 9:07:22 AM 1980 (0x07BC)

It may be a hangup with the installer, that requires a user environment but one is not present when doing an install in the TS. Give it a test as a standalone package so that it can be installed with the System account to verify this theory. It should fail in that scenario also. If not, then it's TS specific and we'll have to look elsewhere.

Well, this is interesting... I advertised the package to a test collection and added the test unit as the only computer in the collection. Running the advertisement reports, I can see that the system accepted the advertisement and the package was received. After that, there is no more status, been hours now... I have gone to the actions tab on the config mgr app and forced update, sw scan, etc. but it is not installing. Also looking through the CCM\Logs folder, but do not see anything pertaining to the advertisement. What specific log(s) should I be looking for on the client side?

Check the execmgr.log for details on software distribution.

Well, found the problem - id10t error... It was due to a change in our packaging... in the past we were only using 32bit OS. Now starting to support x64, and I decided to change the source location for these apps that have both 32 and 64 bit installers. So instead of a separate package and program for each app and platform, I decided to have one package with multiple programs, so changed the path to a parent folder that then contained the x64, and x86 folders. In the command line for the program, I had added the additional folder as part of the command line (i.e. Win7x64\msiexec.exe /i dbrm.msi...) This worked for the other apps, but not for the DBRM... then I realized that i should be putting the additional folder(s) in the 'Start In' line in the properties of the program and not as part of the command line. I changed all the programs for all the packages this way, and all is working great now. Thanks!

jb