Author Topic: Best Practices - Scheduled System Reboots  (Read 6370 times)

Offline Hershel

  • Full Member
  • ***
  • Posts: 154
  • Country: ca
  • Karma: +1/-0
    • View Profile
Best Practices - Scheduled System Reboots
« on: December 18, 2014, 01:00:11 PM »
Curious what other people are doing regarding scheduling system reboots? 


Offline DND ON

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 908
  • Country: us
  • Karma: +23/-0
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #1 on: December 18, 2014, 02:30:05 PM »
I schedule backups weekly, along with weekly resets. If the backup is scheduled for Tuesday night, the reset is scheduled for Wednesday night.

Offline acejavelin

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4064
  • Country: us
  • Karma: +129/-0
  • High-tech, heavy metal redneck!
    • View Profile
    • Like what I do and wanna help out? Send me a donation!
Re: Best Practices - Scheduled System Reboots
« Reply #2 on: January 05, 2015, 10:52:03 PM »
Honestly, unless there is an issue that requires it, I do not schedule regular reboots.

All my systems are backed up monthly.

Offline marcolive

  • Full Member
  • ***
  • Posts: 131
  • Karma: +2/-0
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #3 on: January 05, 2015, 11:09:05 PM »
Had to reboot a 5000 only once to fix a problem related to SIP. Otherwise, we do not program scheduled reboots. We have some systems with an uptime of 2 years or more with no issues.

Offline Tech Electronics

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2973
  • Country: us
  • Karma: +86/-1
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #4 on: January 06, 2015, 06:56:41 AM »
Hershel,

It mainly depends on the site on whether you think there should be a scheduled reboot, but if the system thinks it needs to it will do one on its own. Also keep in mind what happens when a reboot occurs and how long it takes. Some sites, Police Departments for example, do not want to be down at all if it can be avoided.

Thanks,

TE

Offline WallIT

  • Jr. Member
  • **
  • Posts: 76
  • Country: gb
  • Karma: +0/-0
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #5 on: January 09, 2015, 04:29:14 AM »
Can I chip in and ask what the process is to set a scheduled backup if we wish? I see from the DB programming options under Major Reset Scheduling (the choice of word "Major" seems a bit over the top if you ask me)

I appreciate some of these options are obvious, but can someone confirm which of the following needs to be changed in order to have the system reboot weekly?

System Requires Reset = No
Scheduled Reset Time = 00:01
Force Reset If Not Idle = No
Sunday = No
...
Saturday = No
Always Reset On Days Of Week = No [red cross]
Reboot System = No

Many thanks

Offline Tech Electronics

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2973
  • Country: us
  • Karma: +86/-1
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #6 on: January 09, 2015, 08:13:52 AM »
WallIT,

A scheduled backup is done through the following steps.

In the System Administration and Diagnostics program click on the Setup button, the one that looks like a person, and select Manage System Connections.

Select the site that you want to work on and click Edit or click Add if this is a new site.

Select the Backups tab.

In the Backup to folder: field determine the path for the system database backup file folder. The backup file is always stored in a folder named after the connection, but you can specify any path for this folder. The default path is <Public Documents>\5000CP\<name>.

 NOTE: The <name> subfolder in the path will always be labelled the same as the connection name (minus any special characters). This folder is added automatically.

 NOTE: The Schedule Backup feature keeps only a limited number of files as specified in the Backups tab in the Options menu. Any existing database backups in the directory are subject to the file limit.

 NOTE: Do not use a mapped drive for the location because a mapped drive becomes disconnected when you log off of the system. Program your backup to use the full definition of the path.

Scheduled backups will always be saved in a subfolder called ScheduledBackups, e.g. <Public Documents>\5000CP\<name>\ScheduledBackups.

Report backups will always be saved in a subfolder called ReportBackups, e.g. <Public Documents>\5000CP\<name>\ReportBackups.

Select the Enable scheduled backups check box. The following tabs appear to program the scheduled backups for the connection

Data

Notification

Authorization

Scheduling

Test

If the Enable scheduled backups check box does not appear, see Scheduled Backup Troubleshooting Issues for troubleshooting.

Click Save Connection. If all entries are valid, any changes made are saved in the registry.

If there are any invalid entries, an error message appears, and you are moved to the offending tab to make the entries valid. See Scheduled Backup Troubleshooting Issues for a list of programming error messages and troubleshooting tips.

If the Enable test of Scheduled Backup at: START TIME check box is selected in the Test tab, that test is also scheduled at this time (see Test Tab).

You can click Cancel to leave the dialog at anytime. If there are any changes that are not yet saved, a warning message appears.

Before the test of the Scheduled Backup configuration starts:

Log off from the computer. This is not required, but it ensures that the Authorization programming is tested.

Reboot the computer. This is not required, but it simulates the case of a power outage or operating system restart occurring prior to a scheduled backup.

When the backup has had time to complete, log on to the computer and monitor the following results:

If E-mail Notification was programmed and the Notify only if Scheduled Backups fails check box was selected (see Notification Tab), there should only be an e-mail message posted if there was a problem. Check for this first and take action accordingly. If the Notify only if Scheduled Backups fails check box was cleared, there should be a success message.

The Manage Backups window should show the backup databases in the Backups tab and the backup attempt in the History tab (see Managing DB Programming Backups).

The Service Log should contain entries for the backup attempt. See Diagnostics and Troubleshooting for details.

There should be a posting in the Windows Event Viewer, indicating success or failure (and reason). See Diagnostics and Troubleshooting for details.

If the attempt succeeded, the new backup file(s) should now exist in the programmed location(s).

The programming is completed. Make sure the computer is left powered-up with supporting equipment allowing it to connect to the 5000 CP at any time.

Now to answer your question about Major System Reboots. The word Major is to denote that the 5000 will be shutting down and rebooting instead of just restarting it services. As for how to set up a major reset the process is pretty straight forward.

The Scheduled Reset Time is when the system will perform the reset, just make sure this is after the Periodic System Backup which by default is around 11:00 PM.

Then Select a Day of the Week that you want to perform the Scheduled Reset. When you change one from No to Yes the Red X will be removed from Always Reset On Days Of Week. Once the Red X is gone then you can set Always Reset On Days Of Week to Yes.

The Force Reset If Not Idle should only be used if the system is always busy with calls 24 hours a day. What the system will do if it is busy and this flag is not set it will do a delayed system reset with a 24 period denoted by the Manual Override Time [you can only see this if Online Monitor is turned on].

The Reboot System flag causes scheduled delayed resets to reboot the entire system instead of resetting it. For systems equipped with a PS-1, this option reboots the PS-1 and the Base Server.

Thanks,

TE


Offline DND ON

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 908
  • Country: us
  • Karma: +23/-0
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #7 on: January 09, 2015, 08:28:49 AM »
I’ve changed my thinking on Force Reset If Not Idle, to enable the flag. We had a situation where a site was receiving Alarm 16 notifications, indicating the system couldn’t do a reset and was trying again.

Checking the logs showed a call hung up in voice processing, probably due to lack of disconnect signal from the CO. This caused the busy condition preventing the reset. I reset the system during lunch break, and then changed the flag.

Offline WallIT

  • Jr. Member
  • **
  • Posts: 76
  • Country: gb
  • Karma: +0/-0
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #8 on: January 09, 2015, 12:12:19 PM »
Thanks to TE and DND for a comprehensive post!

I have set my time and set Saturdays = Yes. Is this enough to have the system reboot every Saturdays? The wording of the other options is ambiguous.

Always Reset On Days Of Week > do I need this enabled also?
Reboot System > do I need this enabled also?

Sorry to ask again, I just feel the wording is not clear enough.

What about 'System Requires Reset'? what does that do?

Kind regards


Offline Tech Electronics

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2973
  • Country: us
  • Karma: +86/-1
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #9 on: January 09, 2015, 12:43:00 PM »
WallIT,

Per my first post yes you need to set Always Reset On Days Of Week to Yes or it won't reset the system.

According to what you are trying to accomplish you may or may not want to turn on Reboot System. The Flag for Reboot System set to Yes will shut down the entire system and then power back up. This means it will wipe out it's running database, shut down, start up, and load it's backup database from the compact flash. This process is more time consuming than a reset, but if you are not worried about time then doing a full reboot doesn't matter.

The a System Requires Reset flag is just a notification that the system is telling you that it needs a reset. You cannot set this flag or interact with it in anyway, but you can force an immediate reset to see if it clears the flag after you have figured out why it believes it needs a reset of course.

Thanks,

TE

Offline WallIT

  • Jr. Member
  • **
  • Posts: 76
  • Country: gb
  • Karma: +0/-0
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #10 on: January 09, 2015, 12:56:09 PM »
Ok, thanks. I think this is raising more questions that answers.

I just want to be able to reboot the system without it wiping anything. This all started when I wanted to reboot remotely late at night. I couldn't figure out how to do this remotely. I have always walked up to the unit and pressed the buttons to cycle through the options. Is the equivalent of that available through the System Admin & Diagnostics or DB Programming? I don't really need to schedule a weekly reset, I just want to be able to do it ad-hoc but out of hours (remotely).

It is now clear there is a difference between the wording reboot and reset within the Mitel system. I use these words interchangeably when talking about most IT system, but will be more careful when referring to the 5000.

Thanks.


Offline Tech Electronics

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2973
  • Country: us
  • Karma: +86/-1
    • View Profile
Re: Best Practices - Scheduled System Reboots
« Reply #11 on: January 09, 2015, 01:06:03 PM »
WallIT,

The terms Reset and Reboot usually are not considered interchangeable in how they operate, but the end result is similar. Think Reset is Software and Reboot is Hardware (and therefore software). Hopefully that makes more sense now.

If you are wanting to do a reboot of the system to fix a problem after hours then check the reboot option, but let me suggest that you do a scheduled backup prior to the time of the scheduled reboot and obviously after the Periodic System Backup, which is 11 PM by default.

Thanks,

TE


 

Sitemap 1 2 3 4 5 6 7 8 9 10