New-CMSchedule with -start and -end parameters not working
devFofo opened this issue · 2 comments
When running New-CMSchedule -Start $WindowStart -End $WindowEnd -IsUtc:$false -Nonrecurring
with $WindowStart = Wednesday, March 9, 2022 12:00:00 AM
and $WindowEnd = Wednesday, March 9, 2022 1:00:00 AM
I'm getting as a result:
SmsProviderObjectPath : SMS_ST_NonRecurring
DayDuration : 0
HourDuration : 9
IsGMT : False
MinuteDuration : 0
StartTime : 03/08/2022 4:00:00 PM
I've also tried without setting -IsUtc for a very similar answer:
SmsProviderObjectPath : SMS_ST_NonRecurring
DayDuration : 0
HourDuration : 9
IsGMT : False
MinuteDuration : 0
StartTime : 03/08/2022 4:00:00 PM
The same script line worked a year+ ago when I used it to setup multiple schedules.
Checking on SCCM interface you see that it created a 9 hour window, instead of a one hour window and starting at a weird time.
Thanks @devFofo for taking the time to share this with the Configuration Manager documentation team. I’m sorry that you’re having problems, and I want to make sure it gets to the right people that can help. There are a couple of options available to provide the best level of support for this:
- Post on Configuration Manager forums. These are moderated by our community MVPs who are very experienced, knowledgeable, and helpful.
- Use Microsoft Support to search for the issue, or open a case with professional support.
- Contact your Microsoft Premier team, such as a Premier Field Engineer or Technical Account Manager.
If it's a consistently reproducible issue, you can also file feedback via the product feedback portal. For more information, see Feedback for PowerShell.
I revised the New-CMSchedule article in August 2020, and would have tested the examples at that time. So I'm fairly confident they were working. It's possible that a bug was introduced since then, or possibly something wrong with the specific syntax that you're using. Either way, I'm closing this issue as there's nothing actionable for docs at this time. If you find that it's in fact a doc bug, please reopen this issue with additional details.