After wrestling with SCCM trying to be Adobe CS3 Master Collection to deploy silently, I have finally got it working from within the OS but when I included it as part of an OSD task it fails to install with error code 0x80091007 or "The hash value is not correct".
The only fixes I have found from googling is to update the package in the DP, remove and re-add the package to the DP or completly remove the package from SCCM, re-create and re-add to the DP.
None of these have worked.
Does anybody have any ideas?
Yep. I waited until the package was removed and the re-added it.
Have you queried the logs to see more detail on why its failing? either directly by using the F8 command line within the boot image [assuming u have enabled that] or by looking at the logs via the Advertisement of the OSD TS.
Yep, checked to see if it had gone. This is what I am getting from the smsts.log
<![LOG[Install Software failed, hr=0x80091007]LOG]!><time="11:14:04.142+000" date="03-21-2011" component="InstallSoftware" context="" type="3" thread="2680" file="main.cpp:374">
<![LOG[Process completed with exit code 2148077575]LOG]!><time="11:14:04.204+000" date="03-21-2011" component="TSManager" context="" type="1" thread="2600" file="commandline.cpp:1102">
<![LOG[!--------------------------------------------------------------------------------------------!]LOG]!><time="11:14:04.204+000" date="03-21-2011" component="TSManager" context="" type="1" thread="2600" file="instruction.cxx:3010">
<![LOG[Failed to run the action: Install Adobe CS3 Master Collection.
The hash value is not correct. (Error: 80091007; Source: Windows)]LOG]!><time="11:14:04.220+000" date="03-21-2011" component="TSManager" context="" type="3" thread="2600" file="instruction.cxx:3101">
I've just created a new task sequence in case something in that is not working.
I created a new task and I am still getting the same error.
Are the files downloaded locally and run from the client or run from the DP?
running from the DP may prevent the files ending up mismatched when on client.
The other trick is refrsh DP then immediatly update DP.
are you following distmgr.log on the server when you refresh?
be careful opening the DP directory in windows explorer, it may create desktop.ini files or thumbnail files which then make the hash invalid.
I've refreshed/updated the package and you can see this happening in the distmgr.log on the server - everything complete fine.
When running the task and having the content accessed directly I am still getting the same error.
Are there any logs on the server that contain the hash of the package so I can cross reference it when the hash in the smsts.log on the client?
Just had a look run dir /s /a:h on the source directory that the files are copied from and there are no hidden files. Binary differential replication is not enabled on this package.
Just to get more info.... How are you deploying this as part of the OSD TS? via Collection Variables or via Install Software install in your TS? (or some other way)
Are you running SCCM Natively or in Mixed Mode?
Quite the puzzler tho...
Also, is your DP the same or different server as your site server?
Is BITS and associated services running correctly? I seem to recall that after a recent update - possibly R3 or some hotfixes - while everything was working correctly as far as current packages went, when i went to update them, things werent working as expected, for no apparent reason.
Cant remember exactly what it was offhand, but I did have to remove the BITS Server Extensions (in the 2008 Features list) from the DP server (or might have been site server), reboot, install it again, reboot, and help / poke SCCM's services until things were working again.
I did read that rarely, this can fail for no reason and something like the above is the cure, but take with a pinch of salt
SCCM is running in Mixed Mode
The DP is on the same server as the site server
BITS appears to be running correctly as I can download and install the problem package from within the OS after advertising it. It's only when it is part of the OSD TS that it causes a problem. I haven't installed R3 yet.
check the web server logs on the dp point for errors from that client. I've seen the appconfig in IIS cause some strangeness like this. I would expect all installs to fail though, not just osd ones.
There are currently 1 users browsing this thread. (0 members and 1 guests)