Unfortunately, I don't think there is any way around it. At the very start of the process, prior to the actual start of the task sequence the client receives its "orders" so to speak. This includes all the required packages, versions, etc. When the time comes to use a package the client refers back to this original inventory to verify that what it is pulling from the DPs is valid.
When a package is updated while a TS is running, when it comes time to access that package what the client finds on the DP no longer matches what SCCM told it to expect. So, in the client's view the content it keeps trying to access is corrupt (the hash mismatch). We had to do a number of things to get around this. One, we leapfrog packages. Once a package is in the TS it is never touched again. If we need to make a revision we create a new package, update it and once it is out on the DPs we swap it into the TS. There was one package in particular that we could not do this with (its content was automatically updated as part of a backend process). In that case we had to set aside a downtime window where no builds could be performed. Mike From: [email protected] [mailto:[email protected]] On Behalf Of Miller, Todd Sent: Thursday, May 01, 2014 2:51 PM To: [email protected] Subject: [MDT-OSD] TS gathering package version I run into trouble occasionally when I update a package that may be part of a task sequence. It seems that the TS collects the version number of the package at the beginning of the TS and then if the package is updated while the TS is running, it fails from a hash mismatch. The TS running on the client is looking for an older package (and hash). I wonder when the package version is collected, and is there any command I can run to make the package number be recomputed during the TS. For instance, if I have a TS line that says Install Notepad, there is no package number listed in the TS - it just says install this package. At what point is the package ID/version captured? Can I get around this problem? I hesitate to update packages because in a place like mine, there is always someone running a deployment and there is no good time to update packages. Are there steps I can take to help mitigate this problem? The package might be called explicitly in the Task Sequence or it might be called by dynamic packages reference ie -- Package001=XXX00001a, Package002=xxx000067, etc. When does the version get captured for xxx00001a? Why not just in time? What do you do about this? ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues
