What I want to do is have the OSD TS be Required and run on devices as a set schedule.
This is the way I configured it: Required Deploy set on Schedule
Rerun behavior - "Always Rerun on Failure"
Now OSD is deployed with success. The old deploy and schedule is deleted.
Later a new deploy is created to that device with a different schedule. What I've found is that even though a new deploy with schedule was set required for the device it will never re-run as it remembers from the past deploy that it was successful. This is the same effect if "Never Rerun" was selected for rerun behavior.
So if I want a tech to be able to in the future set a new deploy schedule to this device that had a past Successful Deploy I should set in the original deploy "Always Rerun". This will allow for future new deploys and schedules to run the same TS again if a tech wanted to deploy it.
Does that make sense ? Any dangers of setting it to "Always Rerun" then deleting the deploy after it was successful to the collection ?
Here's some explanations of Rerun behavior I'm referring to.
Thanks for any comments and suggestions on this.
Again, my goal is to allow Techs to deploy a required task sequence to a collection. Delete the deploy after success. Then be able to deploy the same Task sequence again in the future to same devices without it being blocked. Issue right now is it is going right to "success" on rerun attempt and logs say "this program set to never rerun"
To get the above solution to Work you have to set the Deployment of the TS to Always rerun. The risk is of course that your admins forgets to remove the deployments and that the computers are reintalled.
As you use a set Schedule that is what is needed to get it to Work.
From my testing "Always Rerun" wouldn't be acceptable for Required OS Deploy. This is because once a deploy completes with success within about 15 minutes or so it will start to deploy OS again to the same device.
This leaves me with "Re-run on Failure" that is fine and was my original plan however it goes back to the problem I have. If a tech tries to create a new Deployment with a new schedule (date/time) in the future for this task sequence it will run and then not do anything. Checking the logs it will always say "Success - this program will not Re-run" this is because it remembers the past the old deploy schedule where it did not exit with a failure.
That means no matter what new schedule I set I am unable to set a required OS deploy to this device no matter what. I can make it "available" however that is not the purpose of my project and won't be acceptable.
We must have the deploy be Required and after successful reimage allow future scheduling for OSD of the same device. Right now that doesn't seem possible without creating a new Task Sequence with a new program ID so it's seen as a new program to deploy.
Am I not understanding something here ?
These are the details of Required Deploy Re-run settings again
Deleting manual registry entries wouldn't be practical.
These are the requirements from our managers we are trying to achieve:
1. Allow remote field techs across more than 100 offices limited access to SCCM console to schedule and monitor OS Required deployments (zero touch) to their respective office site without interaction with enterprise admins (this has already been set as far as rights and they are provided console access)
2. Allow admins to delete and reschedule the same required OS deployment to target machines (student campuses) at any time in the future without manual effort per device
The original plan was to set the Required Deploy to Re-run on Failure (default) with the understanding that once a successful Deploy had been deleted we would be able to create a new Required Deploy with a new schedule to target the same devices again in the future. This doesn't seem to be the case as the SCCM client keeps a history that in the past OSD ran with success and will not run again the OSD even with a new Required Schedule. It's logical to me that if I set it that it must run Required/Mandatory at a new time and schedule then it should always do so despite past execution results. However this doesn't seem to be the case.
Anyone then have suggestions on how I should go about to meet the manager's requirements for this project as described in 1 & 2 ?