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]] 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
