Controlling Program Deployment Execution Time
In System Center Configuration Manager (ConfigMgr) 2007 and beyond, the time that a program for a required deployment is enforced (or run) by the client is generally thought to be the assignment schedule time(s) defined within the deployment.
Assignment Schedule
As discussed in my Recurring Advertisements post, this isn’t exactly the case though. Basically, if a client misses an assigned time for whatever reason, it will catch up meaning that it very well can run at just about any time after the scheduled time. As an example, if you schedule something to run every night at 10PM, like a shutdown or restart, and if the system is not on at that time, it will run the shutdown or restart when it is on again. This of course could be very disruptive to the end-user and bad for your reputation (not that we ever care about those things).
There are a couple of different ways to handle this:
- Use Maintenance Windows. This works quite well; however, maintenance windows will also affect every required deployment targeted at the system. This may be undesirable (or maybe not, that’s for you to determine). You can of course exclude deployments from maintenance windows, but you are now just creating work for yourself.
- Use a simple batch file to check the time and only execute the shutdown or restart if within a given time frame. Here is an example batch file to do just this. This is slightly more complex than simply running shutdown.exe because now you need to make the batch file available to the clients, but that’s par for the course with ConfigMgr software distribution and thus shouldn’t be of any actual concern.
To use the above, copy and paste it into a batch file, place this in your content library, create a package referencing the folder where you placed it, and create a program with the following command-line:
ConstrainedReboot.bat 2200 2300
The two parameters after the batch file name are the times (in 24 hour format) in between which (inclusive) that you want the action to happen — line 11 defines the actual action that you would like to happen within the times specified. Outside of these times, the batch just exits gracefully. Make sure that the schedule time(s) for the deployment fall within the time range specified otherwise the action will ever actually be run. And of course, the shutdown.exe command above is just an example and you can change line 11 to be anything you want or need it to be.
Note that there are other ways to possibly address this scenario (like using a task sequence and WMI conditions) but these just add complexity to the process so I won’t detail them here and recommend you stick with #1 or #2 above.
Next Article
Maintenance windows oh maintenance windows, cancel reply.
Notify me of follow-up comments by email.
Notify me of new posts by email.
Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page. Click here for instructions on how to enable JavaScript in your browser.
Very elegant. Very neat. Saving this for later, for sure!
Best explanation of install time windows. The install time of next reboot/power on or next logon makes perfect sense following the appenforce.log install times for a scheduled/required app.
Secure Infrastructure Blog
by the Secure Infrastructure team at Microsoft
Run a Configuration Manager Package / Program at every logon for a user.
Recently I was working with a customer who requirement to have a Toast Notification pop up every time a user logged into their computer for a pending Windows 10 Feature Update.
They decided to leverage the functionality of Toast Notification using Windows 10 Toast Notification Script – imab.dk which allows for everything they needed, customized text, personalized greeting, the ability to snooze the reminder and it can be used with Configuration Manager. Now we just had to figure out how to display this every time a user logs on to their computer after the Feature Update is deployed.
Now, I won’t go into how to configure the Toast Notification Script or create the Package or Program as this would be outside the scope of this blog post and I will post that later, but will focus on the scheduling options required to have it run every time a user logs on and not just once, as this turned out to be not as straight forward but makes perfect sense.
Setup the Deployment
If you setup the Deployment with a simple assignment schedule of “Log on” with a Rerun behavior of “Always rerun program” as seen below, the Program will execute the next time a user logs onto the Computer, but will only execute once per user.
To have the Program execute for every logon you need to have a reoccurring schedule for the Package in addition to the “Log on” option, so we added a Monthly reoccurring schedule as seen below.
Now, every time a user logs on to the Computer the Program is executed.
Reviewing this it does make perfect sense as with only the “Log on” option, although you would think it is every logon, how would you make it so it only occurred once or once per user? By adding the reoccurring schedule, you are telling ConfigMgr you want this to run more than once for each user.
I know this is a specialty use case using “Log on”, as this is the first time I have had to do this, but now that I know this – it is a great way to use the Toast Notifications.
Share this:
- System Center
Leave a Reply Cancel reply
Discover more from secure infrastructure blog.
Subscribe now to keep reading and get access to the full archive.
Type your email…
Continue reading
You must be logged in to post a comment.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Create phased deployments with Configuration Manager
- 6 contributors
Applies to: Configuration Manager (current branch)
Phased deployments automate a coordinated, sequenced rollout of software across multiple collections. For example, deploy software to a pilot collection, and then automatically continue the rollout based on success criteria. Create phased deployments with the default of two phases, or manually configure multiple phases.
Create phased deployments for the following objects:
- The phased deployment of task sequences doesn't support PXE or media installation
- Application
- You can't use an automatic deployment rule (ADR) with a phased deployment
Prerequisites
Security scope.
Deployments created by phased deployments aren't viewable to any administrative user that doesn't have the All security scope. For more information, see Security scopes .
Distribute content
Before creating a phased deployment, distribute the associated content to a distribution point.
Application : Select the target application in the console and use the Distribute Content action in the ribbon. For more information, see Deploy and manage content .
Task sequence : You have to create referenced objects like the OS upgrade package before creating the task sequence. Distribute these objects before creating a deployment. Use the Distribute Content action on each object, or the task sequence. To view status of all referenced content, select the task sequence, and switch to the References tab in the details pane. For more information, see the specific object type in Prepare for OS deployment .
Software update : create the deployment package and distribute it. Use the Download Software Updates Wizard. For more information, see Download software updates .
Phase settings
These settings are unique to phased deployments. Configure these settings when creating or editing the phases to control the scheduling and behavior of the phased deployment process.
Optionally, use the following Windows PowerShell cmdlets to manually configure phases for software update and task sequence phased deployments:
- New-CMSoftwareUpdatePhase
- New-CMTaskSequencePhase
Criteria for success of the first phase
Deployment success percentage : Specify the percent of devices that need to successfully complete the deployment for the first phase to succeed. By default, this value is 95%. In other words, the site considers the first phase successful when the compliance state for 95% of the devices is Success for this deployment. The site then continues to the second phase, and creates a deployment of the software to the next collection.
Number of devices successfully deployed : Specify the number of devices that need to successfully complete the deployment for the first phase to succeed. This option is useful when the size of the collection is variable, and you have a specific number of devices to show success before moving to the next phase.
Conditions for beginning second phase of deployment after success of the first phase
Automatically begin this phase after a deferral period (in days) : Choose the number of days to wait before beginning the second phase after the success of the first. By default, this value is one day.
Manually begin the second phase of deployment : The site doesn't automatically begin the second phase after the first phase succeeds. This option requires that you manually start the second phase. For more information, see Move to the next phase .
This option isn't available for phased deployments of applications.
Gradually make this software available over this period of time (in days)
Configure this setting for the rollout in each phase to happen gradually. This behavior helps mitigate the risk of deployment issues, and decreases the load on the network that is caused by the distribution of content to clients. The site gradually makes the software available depending on the configuration for each phase. Every client in a phase has a deadline relative to the time the software is made available. The time window between the available time and deadline is the same for all clients in a phase. The default value of this setting is zero, so by default the deployment isn't throttled. Don't set the value higher than 30.
Configure the deadline behavior relative to when the software is made available
Installation is required as soon as possible : Set the deadline for installation on the device as soon as the device is targeted.
Installation is required after this period of time : Set a deadline for installation a certain number of days after device is targeted. By default, this value is seven days.
Automatically create a default two-phase deployment
Start the Create Phased Deployment wizard in the Configuration Manager console. This action varies based on the type of software you're deploying:
Application : Go to the Software Library , expand Application Management , and select Applications . Select an existing application, and then choose Create Phased Deployment in the ribbon.
Software update : Go to the Software Library , expand Software Updates , and select All Software Updates . Select one or more updates, and then choose Create Phased Deployment in the ribbon.
This action is available for software updates from the following nodes:
- All Software Updates
- Software Update Groups
- Windows Servicing, All Windows Updates
- Office 365 Client Management, Office 365 Updates
Task sequence : Go to the Software Library workspace, expand Operating Systems , and select Task Sequences . Select an existing task sequence, and then choose Create Phased Deployment in the ribbon.
On the General page, give the phased deployment a Name , Description (optional), and select Automatically create a default two phase deployment .
Select Browse and choose a target collection for both the First Collection and Second Collection fields. For a task sequence and software updates, select from device collections. For an application, select from user or device collections. Select Next .
The Create Phased Deployment wizard doesn't notify you if a deployment is potentially high-risk. For more information, see Settings to manage high-risk deployments and the note when you Deploy a task sequence .
On the Settings page, choose one option for each of the scheduling settings. For more information, see Phase settings . Select Next when complete.
On the Phases page, see the two phases that the wizard creates for the specified collections. Select Next . These instructions cover the procedure to automatically create a default two-phase deployment. The wizard lets you add, remove, reorder, edit, or view phases for a phased deployment. For more information on these additional actions, see Create a phased deployment with manually configured phases .
Confirm your selections on the Summary tab, and then select Next to complete the wizard.
Starting on April 21, 2020, Office 365 ProPlus is being renamed to Microsoft 365 Apps for enterprise . For more information, see Name change for Office 365 ProPlus . You may still see the old name in the Configuration Manager product and documentation while the console is being updated.
Optionally, use the following Windows PowerShell cmdlets for this task:
- New-CMApplicationAutoPhasedDeployment
- New-CMSoftwareUpdateAutoPhasedDeployment
- New-CMTaskSequenceAutoPhasedDeployment
Create a phased deployment with manually configured phases
Create a phased deployment with manually configured phases for a task sequence. Add up to 10 additional phases from the Phases tab of the Create Phased Deployment wizard.
You can't currently manually create phases for an application. The wizard automatically creates two phases for application deployments.
Start the Create Phased Deployment wizard for either a task sequence or software updates.
On the General page of the Create Phased Deployment wizard, give the phased deployment a Name , Description (optional), and select Manually configure all phases .
From the Phases page of the Create Phased Deployment wizard, the following actions are available:
Filter the list of deployment phases. Enter a string of characters for a case-insensitive match of the Order, Name, or Collection columns.
Add a new phase:
On the General page of the Add Phase Wizard, specify a Name for the phase, and then browse to the target Phase Collection . The additional settings on this page are the same as when normally deploying a task sequence or software updates.
On the Phase Settings page of the Add Phase Wizard, configure the scheduling settings, and select Next when complete. For more information, see Settings .
You can't edit the phase settings, Deployment success percentage or Number of devices successfully deployed , on the first phase. These settings only apply to phases that have a previous phase.
The settings on the User Experience and Distribution Points pages of the Add Phase Wizard are the same as when normally deploying a task sequence or software updates.
Review the settings on the Summary page, and then complete the Add Phase Wizard.
Edit : This action opens the selected phase's Properties window, which has tabs the same as the pages of the Add Phase Wizard.
Remove : This action deletes the selected phase.
There is no confirmation, and no way to undo this action.
Move Up or Move Down : The wizard orders the phases by how you add them. The most recently added phase is last in the list. To change the order, select a phase, and then use these buttons to move the phase's location in the list.
Review the phase settings after changing the order. Make sure the following settings are still consistent with your requirements for this phased deployment:
- Criteria for success of the previous phase
- Conditions for beginning this phase of deployment after success of the previous phase
Select Next . Review the settings on the Summary page, and then complete the Create Phased Deployment wizard.
- New-CMSoftwareUpdateManualPhasedDeployment
- New-CMTaskSequenceManualPhasedDeployment
After you create a phased deployment, open its properties to make changes:
Add additional phases to an existing phased deployment.
If a phase isn't active, you can Edit , Remove , or Move it up or down. You can't move it before an active phase.
When a phase is active, it's read-only. You can't edit it, remove it, or move its location in the list. The only option is to View the properties of the phase.
An application phased deployment is always read-only.
Manage and monitor phased deployments:
- Software update
- Task sequence
Was this page helpful?
Additional resources
How to rerun a Task Sequence in ConfigMgr using PowerShell
I’ve written about this topic previously and also written a small PowerShell based tool to help administrators ease the pain of rerunning a task sequence. Recently, while developing a solution for a Windows 10 servicing project I needed a solution to rerun a task sequence at a given time. My previous solution consisted of removing the WMI object referring to the schedule for the task sequence deployment and restart the ConfigMgr client forcing it to pull down policies and check against it’s local policy and re-running the deployment.
Given this method is a well known and working one, I wanted to explore if there was a way where I did not have to restart the ConfigMgr client, and simply enforce the task sequence to run straight away.
Modifying the assignment
It may not be known by every ConfigMgr admin, but many of us know that the ConfigMgr client keeps track of it’s policy locally in WMI, more specifically in the root\ccm\policy\machine\actualconfig you can explore the different set of policies that’s currently in effect. Within a class named CCM_TaskSequence, there exists an instance of each advertisement for task sequences. Each instance has two properties that we need to be aware of:
- ADV_MandatoryAssignments
- ADV_RepeatRunBehavior
With this in mind, we can take advantage of these two properties and directly change the local policy and set it as mandatory and always rerun, even if that was not the original configuration made in the ConfigMgr console when it was deployed. This will help us mimic the behavior required for our goal of re-running a task sequence deployment (previously known as assignment back in the days). However, there’s one last piece of the puzzle we’ve not been talking about yet and that’s the requirements of triggering the schedule for the task sequence deployment. For this, we require PackageID for the task sequence located in a class named CCM_SoftwareDistribution. With the PackageID property known to us, we can determine the correct ScheduleID from a class named CCM_Scheduler_History located in the namespace of root\ccm\scheduler. Finally with the ScheduleID value at hand, we can invoke the TriggerSchedule method from a class named SMS_Client located in the namespace of root\ccm.
Sample code
Below are the code that will accomplish our goal, re-running a task sequence deployment on a ConfigMgr client using PowerShell:
Break down of sample code
Let’s take a look at how we can translate all of the above into some usable PowerShell code.
First off, we need to have the name of a task sequence at our disposal, that’s the single piece of information we need to start of with for this to work.
After this, we need to retrieve the PKG_PackageID property from the CCM_SoftwareDistribution class for the instance that matches our task sequence name.
Now we can go ahead and attempt to retrieve the ScheduleID property needed for triggering the task sequence deployment. To get our hands on it, we can retrieve the instance matching the PKG_PackageID property that we’ve stored in $SoftwareDistributionPolicy. A note here though, if you’d have several deployments for a single task sequence, the query below would return a string array containing all the ScheduleID’s. Let’s say that you have a task sequence deployment with the purpose of being Available and another deployment set as Required, you’d see both here. I strongly encourage you to manage this in your code, but for now we’re assuming that there’s only one ScheduleID returned from the below code.
In the case where a task sequence has already been deployed and executed before, and the rerun behavior has not been set to Always rerun, we need to make sure the local policy for the task sequence deployment is changed. This can be done with the following code below.
Another thing we need to ensure is that the ADV_MandatoryAssignments property of the $TaskSequencePolicy instance is set to True.
And for the final step, we need to trigger the schedule associated with the task sequence deployment.
That concludes the break down of the sample code that will rerun a task sequence deployment on a ConfigMgr client.
Nickolaj Andersen
Chief Technical Architect and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences such as Microsoft Ignite, NIC Conference and IT/Dev Connections including nordic user groups.
Cancel reply
Save my name, email, and website in this browser for the next time I comment.
It would be interesting to know if its possible to run/rerun a required deployed task sequence on the client with standard user (no admin) rights?
Amazing, well done! I struggled with the Policy part so was getting errors. Such an under the hood explanation. Excellent!
Should the second line include the ADV_AdvertisementID property as well, like below?
$SoftwareDistributionPolicy = Get-WmiObject -Namespace “root\ccm\policy\machine\actualconfig” -Class “CCM_SoftwareDistribution” | Where-Object { $_.PKG_Name -like $TaskSequenceName } | Select-Object -Property PKG_PackageID, ADV_AdvertisementID
I ended up just commenting out the select statement.
You may also like
Unpacking the Microsoft Intune MDM Certificate
In this post we take a small deep-dive into the Intune MDM certificate and talk about OID's and how they can be leveraged to elevate your trust in the device identity.
Setup app registration for usage with IntuneWin32App module
Some time ago, Microsoft announced that the Microsoft Intune PowerShell enterprise application, that many of us had made use of throughout the years, would be removed. This was stated in a message that read similar to:...
OOBE will force you to quality update during onboarding
Introduction Update 21 September 2024We are happy and proud that we could have influence on the decision to wait with this implementation. Microsoft just announced that they will postpone this rollout 🎉 Microsoft...
Copyright © 2024. Created by MSEndpointMgr. Powered by WordPress
- YouTube – Jungling the Cloud
- Intune App Factory
- Intune Debug Toolkit
- CloudLAPS Community Edition
- Modern Driver Management
- Modern BIOS Management
- ConfigMgr OSD FrontEnd
- ConfigMgr WebService
- ConfigMgr Prerequisites Tool
- Driver Automation Tool
- Console Extension
- Active Directory (5)
- AdminService (1)
- Android (11)
- App Protection Policies (8)
- App Registration (2)
- Application Management (31)
- Application Proxy (3)
- Automation (32)
- Autopilot (17)
- Azure Automation (14)
- Azure MFA (4)
- Azure Monitor (4)
- Azure Services (5)
- Boot Image (4)
- Certificate Distribution (11)
- Cloud Attach (1)
- Cloud Management Gateway (9)
- Co-management (6)
- Compliance Settings (9)
- Conditional Accesss (4)
- ConfigMgr (324)
- ConfigMgr Current Branch (4)
- Console Extension (5)
- Deployment (3)
- Desktop Analytics (1)
- Discovery Methods (2)
- Endpoint Analytics (7)
- Endpoint Protection (4)
- Entra ID (38)
- Entra ID Connect (7)
- Exchange (1)
- Featured Posts (3)
- Graph API (13)
- Group Policy (2)
- Hybrid Entra Join (7)
- Hybrid Exchange (1)
- Hyper-V (2)
- Identity (18)
- Intune (137)
- Intune App Wrapper Tool (2)
- Intune Graph API (10)
- Jamf Pro (2)
- Log Analytics (12)
- Mac Enrollment (1)
- Microsoft Defender (4)
- Microsoft Defender ATP (2)
- Microsoft Endpoint Manager (25)
- Microsoft Graph (4)
- Microsoft Planner (1)
- Microsoft Teams (3)
- Modern Driver Management (10)
- Modern Management (17)
- Office 365 (10)
- Office 365 Pro Plus (3)
- Offline Image Servicing (7)
- Operating System Deployment (74)
- PowerBI (3)
- PowerShell (165)
- Proactive Remediations (8)
- Quick Tips (2)
- Remote Access (1)
- Remote Desktop (2)
- Reporting (25)
- Role Based Administration (3)
- Security (19)
- Software Center (4)
- Software Updates (23)
- Solutions (1)
- Sponsored Post (8)
- SQL Server (11)
- Status Message Query (1)
- Task Sequence (15)
- Third-Party Software Updates (1)
- Troubleshooting (1)
- Updates and Servicing (1)
- Win32 Apps (11)
- Windows (11)
- Windows 10 (82)
- Windows 11 (3)
- Windows 365 (1)
- Windows ADK (1)
- Windows as a Service (5)
- Windows Server (3)
MSEndpointMgr.com use cookies to ensure that we give you the best experience on our website.
IMAGES
VIDEO
COMMENTS
Assignment schedule: For a Required deployment, specify when the client runs the task sequence. You can add multiple schedules. The assignment schedule can have one of the following configurations: A specific date and time; Monthly, weekly, or custom recurrence pattern; As soon as possible; Log on or log off events
You can deploy a package that runs daily at a specific time. Pick your assignment schedule and time and use “always rerun”
In System Center Configuration Manager (ConfigMgr) 2007 and beyond, the time that a program for a required deployment is enforced (or run) by the client is generally thought to be the assignment schedule time (s) defined within the deployment.
I have created a package using the PowerShell AppDeploy Toolkit and in SCCM it will run " Occurs the Second Tuesday of every 2 months " The Rerun behavior will be set to " Always rerun program ".
If you setup the Deployment with a simple assignment schedule of “Log on” with a Rerun behavior of “Always rerun program” as seen below, the Program will execute the next time a user logs onto the Computer, but will only execute once per user. Deployment Options with only Log on Schedule.
Specify an array of schedule objects. A schedule object defines the mandatory assignment schedule for a deployment. To create a schedule object, use the New-CMSchedule cmdlet.
Example is if I schedule the deployment to become available at 6pm today and set Assignment Schedule as "as soon as possible". Will the application install as soon as possible after 6pm? Or will it install just as soon as possible?
Applies to: Configuration Manager (current branch) Phased deployments automate a coordinated, sequenced rollout of software across multiple collections. For example, deploy software to a pilot collection, and then automatically continue the rollout based on success criteria.
This will help us mimic the behavior required for our goal of re-running a task sequence deployment (previously known as assignment back in the days). However, there’s one last piece of the puzzle we’ve not been talking about yet and that’s the requirements of triggering the schedule for the task sequence deployment.
All the steps needed to create SCCM Windows 10 Task Sequence for your Windows 10 deployments using SCCM