OPERATING SYSTEM PATCHING Sample Clauses

OPERATING SYSTEM PATCHING. When software vulnerabilities are revealed and addressed by a vendor patch, Opus obtains the patches from the vendor and categorizes the urgency of application as either "critical" or "non- critical" in nature. The determination of the critical/non-critical nature of patches is solely at the discretion of Opus, and Opus shall have no liability with respect to such determination. Opus will conduct testing for patches in its lab and on its internal production environment. Patches will be applied after they have been approved and qualified by Opus technicians. Non-critical patches are typically applied on a monthly basis whereas critical patches are applied on an `as needed' basis. Opus will apply any vendor supplied patch to supported software within one (1) business day of receiving a written request from Customer. Patches will be applied with the understanding that the patch has not been fully tested by Opus, and no guarantees are made by Opus as to the outcome of application of such patches. Opus will only apply vendor supplied and vendor supported patches. Customer will be notified via support ticket prior to the application of patches, unless agreed to otherwise.
AutoNDA by SimpleDocs
OPERATING SYSTEM PATCHING ilicomm will provide a patching service as part of its Fully Managed service unless otherwise stated on the Order Form or ilicomm has received a specific request from the Customer in writing or via the ilicomm ticketing system. Where the Customer has agreed for ilicomm to proactively apply patches these will be applied outside of Normal Business Hours unless the Customer requests for these to be schedule within Normal Business Hours. In the event that we become aware of critical updates, we will contact the Customer to arrange the earliest opportunity to apply these patches which is convenient to the Customer.
OPERATING SYSTEM PATCHING. This feature includes the scheduled application of vendor recommended patches to the base Operating System on an “as-needed” basis. If patches are classified urgent by vendor due to a security risk; or if Customer requests that a patch be classified urgent then LightEdge will perform an emergency patch during next scheduled Emergency Maintenance window. LightEdge will not apply 3rd party patches to Operating System, patches to applications, patches to software or software library patches as part of this Service. If patching performed during previously agreed upon custom patching schedule and if Customer has agreed upon reboots after patching then LightEdge shall reboot Device without any further notification to Customer. If patching performed outside of a Scheduled Maintenance window requires a reboot of Customer Device then LightEdge will make a reasonable effort to contact Customer. If Customer cannot be reached after such reasonable effort then LightEdge reserves the right to reboot Customer Device without further notification. Any outage caused by application of operating system patches performed as part of this feature shall not be grounds for any SLA credit. Customer agrees to not hold LightEdge responsible for any unanticipated side effects or issues caused by this feature. Customer is responsible for checking status of Device and applications after such patches are applied. Upon discovery by Customer of any abnormality LightEdge will provide assistance in backing out any such patches. LightEdge will not be held responsible if patches cannot be backed out or if Customer Device cannot reasonably be returned to a pre-patch state. Customer has the option to “opt-out” or “opt-in” this particular feature at any time.
OPERATING SYSTEM PATCHING. This feature includes the scheduled application of vendor recommended patches to the base Operating System on an “as-needed” basis. If patches are classified “Urgent” by a vendor due to a security risk, or if Customer requests that a patch be classified as an Urgent Incident Priority, then Bright Bear will perform an emergency patch during next scheduled emergency Maintenance Window. Bright Bear will not apply 3rd party patches to Operating Systems, patches to applications, patches to software or software library patches as part of this Service. If patching was performed during a previously agreed upon custom patching schedule, and if Customer has agreed upon reboots after patching, then Bright Bear shall reboot Devices without any further notification to Customer. If patching performed outside of a scheduled Maintenance Window requires a reboot of Customer Devices, then Bright Bear will make a reasonable effort to contact Customer. If Customer cannot be reached after such reasonable effort, then Bright Bear reserves the right to reboot Customer Devices without further notification. Any Service Outage caused by application of Operating System patches performed as part of this feature shall not be grounds for any Service Credit (as defined in Section 10.2). Customer agrees to not hold Bright Bear responsible for any unanticipated side effects or issues caused by this feature. Customer is responsible for notifying Bright Bear of any custom applications that may be affected by applying Operating System patches. In the case of custom applications, Customer is responsible for providing pre- update and post-update steps for Bright Bear engineers to follow and for approving any non-critical Operating System patches. This feature does not include application patches. Customer is responsible for applying any application patches as required. Customer is responsible for checking status of Devices and applications after such patches are applied. Upon discovery by Customer of any abnormality, Bright Bear will provide assistance in backing out any such patches, where possible. Bright Bear will not be held responsible if patches cannot be backed out or if Customer Devices cannot reasonably be returned to a pre-patch state. Customer has the option to “opt-out” or “opt-in” to this particular feature at any time, with written notice to Bright Bear.

Related to OPERATING SYSTEM PATCHING

  • System Logging The system must maintain an automated audit trail which can 20 identify the user or system process which initiates a request for PHI COUNTY discloses to 21 CONTRACTOR or CONTRACTOR creates, receives, maintains, or transmits on behalf of COUNTY, 22 or which alters such PHI. The audit trail must be date and time stamped, must log both successful and 23 failed accesses, must be read only, and must be restricted to authorized users. If such PHI is stored in a 24 database, database logging functionality must be enabled. Audit trail data must be archived for at least 3 25 years after occurrence.

  • Network Resource Interconnection Service (check if selected)

  • System Upgrades The Connecting Transmission Owner shall procure, construct, install, and own the System Upgrade Facilities and System Deliverability Upgrades described in Attachment 6 of this Agreement. To the extent that design work is necessary in addition to that already accomplished in the Class Year Interconnection Facilities Study for the Interconnection Customer, the Connecting Transmission Owner shall perform or cause to be performed such work. If all the Parties agree, the Interconnection Customer may construct System Upgrade Facilities and System Deliverability Upgrades.

  • Metering The Interconnection Customer shall be responsible for the Connecting Transmission Owner’s reasonable and necessary cost for the purchase, installation, operation, maintenance, testing, repair, and replacement of metering and data acquisition equipment specified in Attachments 2 and 3 of this Agreement. The Interconnection Customer’s metering (and data acquisition, as required) equipment shall conform to applicable industry rules and Operating Requirements.

  • Infrastructure (a) The Borrower has and will maintain a sufficient infrastructure to conduct its business as presently conducted and as contemplated to be conducted following its execution of this Agreement.

  • System Maintenance The Trust understands that USBFS will perform periodic maintenance to the System(s), which may cause temporary service interruptions. To the extent possible, USBFS shall notify the Trust of all planned outages and will perform any necessary maintenance during non-business hours.

  • Construction Services 4,500 thousand SDR for Japan Post in Group A 15,000 thousand SDR for all other entities in Group A 4,500 thousand SDR for entities in Group B Architectural, engineering and other technical services covered by this Agreement: 450 thousand SDR Other services: 130 thousand SDR List of Entities which procure the services, specified in Annex 4:

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!