What about an idea where you could update ½ of the distribution points, or leave at least one DP on the old package version and then all the inprogress TSes would get their packages from the DP that has the old version and the new TSes would pull from the updated DPs. Then the next day or a few hours later the final DP would be updated.
Is there a way to make that idea work? Could you just leave one unprotected DP with the old version available for a while? When a client queries AD to find a package source, does it take package version into account? From: [email protected] [mailto:[email protected]] On Behalf Of Melvin Backus Sent: Thursday, May 01, 2014 2:21 PM To: [email protected] Subject: [MDT-OSD] RE: TS gathering package version Is there any way to make the server "unavailable" like you can do with load balanced stuff? Do a drain stop so that existing processes will continue to run, then when everything has finished update the package(s). It might be a little inconvenient, but with a bit of scheduling you could likely carve out a time window for updates. Without NLB I don't what else might provide this functionality. Hmm, never tried doing NLB on a single server, I wonder... :) -- There are 10 kinds of people in the world... those who understand binary and those who don't. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Marable, Mike Sent: Thursday, May 01, 2014 3:00 PM To: '[email protected]' Subject: [MDT-OSD] RE: TS gathering package version 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]> [mailto:[email protected]] On Behalf Of Miller, Todd Sent: Thursday, May 01, 2014 2:51 PM To: [email protected]<mailto:[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 ________________________________ 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. ________________________________
