Brad; I can certainly take it under advisement, but the proper formal path for enhancement requests is via the Help Desk that can file a formal enhancement request called a GRIP.  If this is something that represents a key business need for you, a GRIP allows the business justification to be captured so future inclusion of the feature can be productized based on multiple requests from the field. It sounds like what you are asking for is multiple fixed times, or perhaps one or more fixed time windows with an interval for each window.  We would have to look at what the more generic approach would be and what would serve the most varied needs. For now, however, I think you CAN get what you want, or near enough.  I wasn't saying what you had done wouldn't work, I was just clarifying the exact behavior.  In most cases, having the device TRY and check-in and then NOT communicate to the Relay Server because a Condition was not met should be fine.  In fact, since other important things (such as checking for Lock, etc.) happen on an attempted check-in, even if communication with the Relay Server does not happen, you generally do WANT the device to attempt to check in even when the Conditions will not be met to communicate to the Relay Server. The only real issue with that is a bit more overhead on the device due to check ins that may not do very much.  I have not seen that as being an issue in the vast majority of cases.  Is there some way in which the solution you are using is unacceptable?  I would not try and mess with stopping ans starting the agent unless you have a good reason, since that can lead to reliability issues and could end up leaving a device unmanaged due to application errors. Allan

This looks perfect.

 

The Agent on the device tries to contact the relay server at 2100 hrs and then it will evaluate the condition. Since the time 2100 hrs in Agent settings would already be falling in the time you have selected in the condition (20:29 to 23:59) the Agent on the device would be successful in checking into the relay server. This would continue for the next 15 checkins until the time is 23:45.

Brad; Yes, that should work, but there may be some things about it that don't work exactly as you might think. Keep in mind that an interval combined with a fixed time does not mean it will ONLY attempt to check in begining at that fixed time.  An interval means it will attempt to check in whenever it has not attempted to check in for at least that amount of time.  A fixed time means that it will attempt to check in at that time, no matter when it last attempted to check in.  Combining the two is an OR not an AND. When it does attempt to check in, it will evaluate the check in Conditions (if any) and skip those parts of the check in cycle that involve communication with the Relay Server if the Conditions are NOT met.  But there are other things it will do every time it attempts to check in that do not require communicating to the Relay Server.  That includes executing check in commands on installed Packages (e.g. LockAndWipe) and executing Detached Jobs that are pending and whose Detached Conditions have been met. So, as you have configured it, the agent will be attempting to check in in every 15 minutes all around the clock.  But outside the specified time range, it will not communicate to the Relay Server.  For the sake of argument, let's say the last attempt to check in was 20:28.  Since that does not meet the check in Condition, it will not communicate to the Relay Server on that attempt.  The next attempt will be 15 minutes later, at 20:43.  On that attempt it will meet the check in Condition and hence it will communicate to the Relay Server.  The next attempt will be at 20:58, and it will again communicate to the Relay Server.  The next attempt will be at 21:00 due to the fixed time, and then it will be on the schedule you showed. So, using the fixed time will not prevent it from attempting to check in before, but it will also not always force it to happen on specific times.  It will make it check in at that time, and will cause it to begin attempting to check in on the regular times you show.  But if the device were rebooted or some other situation (manual force check in, request check in, etc.) happened, it could go back to attempting to check in every 15 minutes but NOT on the regular times you show. Also note that the agent can't and won't attempt to check in while the device is suspended.  When the device resumes, it will attempt to check in very shortly thereafter, if it has been at least the specified interval since it last attempted to check in.  So, that will tend to get it off the regular schedule you show.  And note that unless you specifically ask it to, the agent won't automatically resume the device from suspend to attempt to check in.  You can configure it to wake up at the specified fixed time, if it is suspended at that time.  That can be useful to ensure that it attempts to check in a least at that time.  Depending on how you have the suspend timeout set, various things can happen.  Note that it will NEVER wake up the device from suspend for an interval based check in attempt, ONLY for a fixed time check in attempt, and only if you specifically ask it to. Allan

Allan, I suppose it would be easier to have a fixed time and then a value for next number of consecutive check-ins, once that next number is reached, resume the next fixed schedule.  Fixed at 2100, 4 Check-In's at a 15 minute interval.  Resume Fixed. I guess you can't have multiple Agent.30 fixed check-ins either.  One at 2100, Next at 2130, Then finally at 2200.  I suppose I could have a series of install and uninstall's Agent.30's to mimic that function.  I think I might play with that. Can you suggest my first paragraph as an enhancement to MSP? Thank You. Brad

Brad; I look at Enable30 as being sort of the "training wheels" of MSP.  It can make it easier to get started, for novice users.  But for more users, creating and using Agent.30 Settings Objects is a more complete solution. Allan

OK, check me here. I would like to create a Check-In schedule to do the following.

Condition Called 'AfterHours', which is defined as:

Start:    Hour 20; Minute 29 End:    Hour 23; Minute 59

This yields 3 hours and 30 Minutes of an 'AfterHours' condition, which I assume means it falls within 'A Permitted Condition'. This 'AfterHours' condition would be wrapped inside an Agent.30 setting called '12Fifteens', which is configured as, Interval and Fixed with:

Hour:  21 Minute:  00 Interval: 15 Condition: AfterHours Force RegDoc: 8 Wake-Up: True

Would this timeline or my flawed logic hold true then?

2029 - AfterHours Condition Begins Begin Agent.30 Hour/Minute/Interval 2100  Check-In 1 of 12 2115  Check-In 2 of 12 2130  Check-In 3 of 12 2145  Check-In 4 of 12 2200  Check-In 5 of 12 2215  Check-In 6 of 12 2230  Check-In 7 of 12 2245  Check-In 8 of 12 w/RegDoc 2300  Check-In 9 of 12 2315  Check-In 10 of 12 2330  Check-In 11 of 12 2345  Check-In 12 of 12 End Agent.30 Hour/Minute/Interval 2359 - AfterHours Condition Ends

Sanity check, I'm I doing this right?

Thanks

Brad

You should be able to create a new setting under Library>Settings.  Type is agent30.setting.xml.  Change the interval from 15 to whatever you like.  You will then need to add that setting to a bundle and get it out to the device for the change to occur.