Tech Advisory

Technology Advice for Small Businesses

powered by Pronto Marketing

Recent Posts

Making sense of workplace computer energy costs

Editor November 13, 2026

Energy savings on office computers are often promised and rarely measured. Before buying new equipment or changing power settings, it helps to know what the current fleet actually draws in each state: off, asleep, idle, and busy.

Start with the arithmetic

The calculation is simple. Multiply a device’s power draw in watts by the hours it runs, divide by 1,000 to get kilowatt-hours, then multiply by the electricity rate. A 100-watt device running 10 hours a day, for example, uses one kilowatt-hour daily. U.S. Energy Information Administration data put the national commercial average near 14 cents per kilowatt-hour in early 2026, with the lowest-cost states closer to 7 to 9 cents. Use the blended rate from your own bill instead, since demand charges and tiered pricing can make the effective cost differ from a published average.

Measure at the wall, not from the label

A power supply’s wattage rating is a ceiling, not a measurement. To learn actual consumption, plug the computer into an inexpensive watt meter or an energy-monitoring smart plug, and record the draw in each state: off, asleep, idle, and under a typical workload. Include the whole desk, because monitors, docking stations, and speakers draw power as well. Sample across a full working week, and use metered power strips or PDUs for server racks. ENERGY STAR applies the same logic when it certifies computers, weighting measured power in off, sleep, and idle modes by assumed time in each to estimate yearly energy. A business can do the same with its actual working hours.

Idle power is where waste hides

Consider an illustration, with the assumptions stated plainly. A desktop averages 40 watts while powered on and 2 watts asleep, and electricity costs 14 cents per kilowatt-hour. Left on all year, it uses about 350 kilowatt-hours and costs roughly $49. If it sleeps outside a 50-hour work week, it uses about 116 kilowatt-hours and costs roughly $16, a saving near $33 per computer. Across 50 computers, that is about $1,600 a year. Energy.gov, citing ENERGY STAR, estimates savings of up to about $30 per computer each year from sleep features, which sits in the same range.

Equipment efficiency and replacement decisions

Efficient hardware helps, though less than people expect. Energy.gov reports that ENERGY STAR labeled computers use 30 to 65 percent less energy than unlabeled ones, depending on usage, and that laptops use much less energy than desktops. Apply 30 to 65 percent to the $49 example and the annual saving is roughly $15 to $32 per machine. That rarely justifies replacing a working computer early, but it is a sound tiebreaker at refresh time. Favor ENERGY STAR certified models, consider laptops and docking stations for staff who do not need desktop power, and include monitors, which draw very little when certified and asleep.

Practical energy-management decisions

Start with settings, which cost nothing. Push sleep and display timers centrally through Group Policy or Microsoft Intune, matching them to real work patterns. Check that overnight patching and remote access still work, since sleeping machines must wake for updates; scheduled wake times or Wake-on-LAN usually solve this. Computers also release heat, so lower power draw can trim cooling needs in warm months. Ask your utility whether it offers incentives for efficient equipment or power management, and review the numbers again after a year, using the original meter readings as the baseline. Report results as dollars per workstation per year, so decision makers can weigh energy against other IT priorities.

Want to know what your office computers really cost to run and where you can cut waste without disrupting staff? Our team can measure your fleet, set up centralized power management, and plan efficient hardware refreshes. Get in touch to start.

What do your office computers really cost to run?

Editor November 13, 2026

A computer’s price tag tells only part of its cost. A few inexpensive measurements and some simple arithmetic reveal what each workstation really costs to run and which energy-management steps pay off.

Start with the arithmetic

The calculation is simple. Multiply a device’s power draw in watts by the hours it runs, divide by 1,000 to get kilowatt-hours, then multiply by the electricity rate. A 100-watt device running 10 hours a day, for example, uses one kilowatt-hour daily. U.S. Energy Information Administration data put the national commercial average near 14 cents per kilowatt-hour in early 2026, with the lowest-cost states closer to 7 to 9 cents. Use the blended rate from your own bill instead, since demand charges and tiered pricing can make the effective cost differ from a published average.

Measure at the wall, not from the label

A power supply’s wattage rating is a ceiling, not a measurement. To learn actual consumption, plug the computer into an inexpensive watt meter or an energy-monitoring smart plug, and record the draw in each state: off, asleep, idle, and under a typical workload. Include the whole desk, because monitors, docking stations, and speakers draw power as well. Sample across a full working week, and use metered power strips or PDUs for server racks. ENERGY STAR applies the same logic when it certifies computers, weighting measured power in off, sleep, and idle modes by assumed time in each to estimate yearly energy. A business can do the same with its actual working hours.

Idle power is where waste hides

Consider an illustration, with the assumptions stated plainly. A desktop averages 40 watts while powered on and 2 watts asleep, and electricity costs 14 cents per kilowatt-hour. Left on all year, it uses about 350 kilowatt-hours and costs roughly $49. If it sleeps outside a 50-hour work week, it uses about 116 kilowatt-hours and costs roughly $16, a saving near $33 per computer. Across 50 computers, that is about $1,600 a year. Energy.gov, citing ENERGY STAR, estimates savings of up to about $30 per computer each year from sleep features, which sits in the same range.

Equipment efficiency and replacement decisions

Efficient hardware helps, though less than people expect. Energy.gov reports that ENERGY STAR labeled computers use 30 to 65 percent less energy than unlabeled ones, depending on usage, and that laptops use much less energy than desktops. Apply 30 to 65 percent to the $49 example and the annual saving is roughly $15 to $32 per machine. That rarely justifies replacing a working computer early, but it is a sound tiebreaker at refresh time. Favor ENERGY STAR certified models, consider laptops and docking stations for staff who do not need desktop power, and include monitors, which draw very little when certified and asleep.

Practical energy-management decisions

Start with settings, which cost nothing. Push sleep and display timers centrally through Group Policy or Microsoft Intune, matching them to real work patterns. Check that overnight patching and remote access still work, since sleeping machines must wake for updates; scheduled wake times or Wake-on-LAN usually solve this. Computers also release heat, so lower power draw can trim cooling needs in warm months. Ask your utility whether it offers incentives for efficient equipment or power management, and review the numbers again after a year, using the original meter readings as the baseline. Report results as dollars per workstation per year, so decision makers can weigh energy against other IT priorities.

Want to know what your office computers really cost to run and where you can cut waste without disrupting staff? Our team can measure your fleet, set up centralized power management, and plan efficient hardware refreshes. Get in touch to start.

How to measure the real energy cost of workplace computers

Editor November 13, 2026

Most businesses know what their computers cost to buy and almost none know what they cost to run. Measuring real consumption, instead of relying on nameplate ratings or rules of thumb, shows where the money goes and which changes are worth making.

Start with the arithmetic

The calculation is simple. Multiply a device’s power draw in watts by the hours it runs, divide by 1,000 to get kilowatt-hours, then multiply by the electricity rate. A 100-watt device running 10 hours a day, for example, uses one kilowatt-hour daily. U.S. Energy Information Administration data put the national commercial average near 14 cents per kilowatt-hour in early 2026, with the lowest-cost states closer to 7 to 9 cents. Use the blended rate from your own bill instead, since demand charges and tiered pricing can make the effective cost differ from a published average.

Measure at the wall, not from the label

A power supply’s wattage rating is a ceiling, not a measurement. To learn actual consumption, plug the computer into an inexpensive watt meter or an energy-monitoring smart plug, and record the draw in each state: off, asleep, idle, and under a typical workload. Include the whole desk, because monitors, docking stations, and speakers draw power as well. Sample across a full working week, and use metered power strips or PDUs for server racks. ENERGY STAR applies the same logic when it certifies computers, weighting measured power in off, sleep, and idle modes by assumed time in each to estimate yearly energy. A business can do the same with its actual working hours.

Idle power is where waste hides

Consider an illustration, with the assumptions stated plainly. A desktop averages 40 watts while powered on and 2 watts asleep, and electricity costs 14 cents per kilowatt-hour. Left on all year, it uses about 350 kilowatt-hours and costs roughly $49. If it sleeps outside a 50-hour work week, it uses about 116 kilowatt-hours and costs roughly $16, a saving near $33 per computer. Across 50 computers, that is about $1,600 a year. Energy.gov, citing ENERGY STAR, estimates savings of up to about $30 per computer each year from sleep features, which sits in the same range.

Equipment efficiency and replacement decisions

Efficient hardware helps, though less than people expect. Energy.gov reports that ENERGY STAR labeled computers use 30 to 65 percent less energy than unlabeled ones, depending on usage, and that laptops use much less energy than desktops. Apply 30 to 65 percent to the $49 example and the annual saving is roughly $15 to $32 per machine. That rarely justifies replacing a working computer early, but it is a sound tiebreaker at refresh time. Favor ENERGY STAR certified models, consider laptops and docking stations for staff who do not need desktop power, and include monitors, which draw very little when certified and asleep.

Practical energy-management decisions

Start with settings, which cost nothing. Push sleep and display timers centrally through Group Policy or Microsoft Intune, matching them to real work patterns. Check that overnight patching and remote access still work, since sleeping machines must wake for updates; scheduled wake times or Wake-on-LAN usually solve this. Computers also release heat, so lower power draw can trim cooling needs in warm months. Ask your utility whether it offers incentives for efficient equipment or power management, and review the numbers again after a year, using the original meter readings as the baseline. Report results as dollars per workstation per year, so decision makers can weigh energy against other IT priorities.

Want to know what your office computers really cost to run and where you can cut waste without disrupting staff? Our team can measure your fleet, set up centralized power management, and plan efficient hardware refreshes. Get in touch to start.

Why VoIP call transfers fail between phone systems

Editor November 11, 2026

A call transfer may seem simple, but behind the scenes, multiple phone systems must coordinate how to pass an active call to another person or number. They do this through SIP messages, which different vendors may handle in their own ways. When systems don’t agree, calls can drop, callers may hear silence, or transfers may fail when dialing an outside number. Understanding how the process works makes these issues easier to troubleshoot.

How a SIP transfer works

A SIP call transfer involves three parties: the transferor, who initiates the transfer; the transferee, whose call is being moved; and the target, who receives the call.

Most transfers use the SIP REFER method, defined in RFC 3515 (The Session Initiation Protocol REFER Method). This RFC defines how one SIP device can ask another to make a new request, such as starting a call to a different destination. The destination is included in the Refer-To header, while the Referred-By header identifies who requested the transfer.

The receiving system then sends a new INVITE, the SIP method used to initiate a call, to the target. It reports the call’s progress through NOTIFY messages, which communicate updates such as whether the new call is ringing or has connected.

The process depends on the type of transfer. A blind transfer sends the call to the target immediately, without first checking their availability. An attended transfer allows the transferor to call the target first and confirm they are available before completing the handoff. It uses the Replaces header, defined in RFC 3891 (The SIP Replaces Header), to identify the existing call that the new call should take over.

For a broader look at how these mechanisms work together, RFC 5589 (Session Initiation Protocol Call Control – Transfer) describes recommended practices and call flows for implementing SIP transfers, including blind and attended transfers.

Where interoperability breaks down

SIP transfer failures usually fall into a few common categories. The first is support mismatch: not every phone system or carrier supports REFER. Microsoft Teams Direct Routing documentation provides an example of how platforms handle this, listing a fallback order of REFER, INVITE with Replaces, and then an internal transfer method that the session border controller (SBC), which manages SIP traffic between networks, cannot see. These fallback methods can behave differently, sometimes leaving callers unable to hear the phone ringing while waiting for an answer.

Header handling is another common issue. A REFER request may not contain all the information needed to route the new call, so Microsoft expects the SBC to preserve the Refer-To and Referred-By headers when creating the new INVITE. That INVITE must go back to the platform’s SIP proxy rather than directly to the telephone network. Rewriting the headers or routing the INVITE elsewhere can break the transfer.

Missing progress messages can also cause failures. The receiving system should respond to REFER with “202 Accepted” and send NOTIFY messages to report progress. If these messages never reach the initiating system, it may time out. If a BYE message, which ends an established call, arrives too early, the original call can drop before the transfer completes.

Firewall rules add another potential obstacle. REFER requests may arrive over new TLS connections from any of the platform’s signaling addresses. Firewalls that allow only specific addresses can block these requests, even when other SIP traffic works normally.

Finally, carrier behavior and platform updates can introduce unexpected problems. A 481 Call/Transaction Does Not Exist response means the receiving system can no longer find the referenced call or transaction. During an attended transfer, this can happen when the transferor’s temporary call to the intended recipient (known as a consultation call) stays on hold long enough for a carrier device to expire it.

Platform changes matter too. In June 2026, Microsoft changed its blind-transfer behavior so its side ends the original call as soon as the SBC accepts the transfer, without waiting for the final result. Configurations that worked under the previous behavior may therefore need to be reviewed.

Practical troubleshooting checks

Start by identifying the transfer type (blind or attended), its direction, and which system receives the REFER request. Capture SIP traces of both a failed and successful transfer using SBC logs or a packet capture, then compare the messages to find where they differ.

Check whether REFER is listed in the Allow header on each leg of the call. If a system does not support REFER, removing it from the advertised methods may force some platforms to use INVITE with Replaces as a temporary workaround.

Next, verify that the new INVITE preserves the Refer-To and Referred-By values and that 202 Accepted and NOTIFY messages reach the system that initiated the transfer. Check message timing too, particularly whether a BYE arrives before the final NOTIFY. If callers hear silence instead of ringing, check REFER support and the handling of 180 Ringing and 183 Session Progress responses, which provide call-progress updates.

Also review firewall rules to ensure all required signaling addresses are allowed, and confirm that destination numbers use the format expected by the next system.
Finally, test internal and external transfers separately, including both blind and attended transfers across desk phones, softphones, and mobile devices. Comparing the results helps identify which system or network connection is causing the failure.

Call transfer failures between your phone system, carrier, or cloud platform can be difficult to diagnose. Our team can capture and analyze SIP traffic, identify where the handoff breaks, and help get your calls transferring reliably. Contact us to start troubleshooting.

Blind, attended, and broken: What happens when phone systems hand off a call

Editor November 11, 2026

Call transfer issues can be difficult to diagnose because users rarely report a rejected SIP REFER. Instead, they simply say the call dropped when they tried to transfer it to a colleague. Behind the scenes, the transfer involves several systems that must coordinate the handoff. When something goes wrong, understanding how these systems interact makes it easier to identify where the transfer failed and why.

How a SIP transfer works

A SIP call transfer involves three parties: the transferor, who initiates the transfer; the transferee, whose call is being moved; and the target, who receives the call.

Most transfers use the SIP REFER method, defined in RFC 3515 (The Session Initiation Protocol REFER Method). This RFC defines how one SIP device can ask another to make a new request, such as starting a call to a different destination. The destination is included in the Refer-To header, while the Referred-By header identifies who requested the transfer.

The receiving system then sends a new INVITE, the SIP method used to initiate a call, to the target. It reports the call’s progress through NOTIFY messages, which communicate updates such as whether the new call is ringing or has connected.

The process depends on the type of transfer. A blind transfer sends the call to the target immediately, without first checking their availability. An attended transfer allows the transferor to call the target first and confirm they are available before completing the handoff. It uses the Replaces header, defined in RFC 3891 (The SIP Replaces Header), to identify the existing call that the new call should take over.

For a broader look at how these mechanisms work together, RFC 5589 (Session Initiation Protocol Call Control – Transfer) describes recommended practices and call flows for implementing SIP transfers, including blind and attended transfers.

Where interoperability breaks down

SIP transfer failures usually fall into a few common categories. The first is support mismatch: not every phone system or carrier supports REFER. Microsoft Teams Direct Routing documentation provides an example of how platforms handle this, listing a fallback order of REFER, INVITE with Replaces, and then an internal transfer method that the session border controller (SBC), which manages SIP traffic between networks, cannot see. These fallback methods can behave differently, sometimes leaving callers unable to hear the phone ringing while waiting for an answer.

Header handling is another common issue. A REFER request may not contain all the information needed to route the new call, so Microsoft expects the SBC to preserve the Refer-To and Referred-By headers when creating the new INVITE. That INVITE must go back to the platform’s SIP proxy rather than directly to the telephone network. Rewriting the headers or routing the INVITE elsewhere can break the transfer.

Missing progress messages can also cause failures. The receiving system should respond to REFER with “202 Accepted” and send NOTIFY messages to report progress. If these messages never reach the initiating system, it may time out. If a BYE message, which ends an established call, arrives too early, the original call can drop before the transfer completes.

Firewall rules add another potential obstacle. REFER requests may arrive over new TLS connections from any of the platform’s signaling addresses. Firewalls that allow only specific addresses can block these requests, even when other SIP traffic works normally.

Finally, carrier behavior and platform updates can introduce unexpected problems. A 481 Call/Transaction Does Not Exist response means the receiving system can no longer find the referenced call or transaction. During an attended transfer, this can happen when the transferor’s temporary call to the intended recipient (known as a consultation call) stays on hold long enough for a carrier device to expire it.

Platform changes matter too. In June 2026, Microsoft changed its blind-transfer behavior so its side ends the original call as soon as the SBC accepts the transfer, without waiting for the final result. Configurations that worked under the previous behavior may therefore need to be reviewed.

Practical troubleshooting checks

Start by identifying the transfer type (blind or attended), its direction, and which system receives the REFER request. Capture SIP traces of both a failed and successful transfer using SBC logs or a packet capture, then compare the messages to find where they differ.

Check whether REFER is listed in the Allow header on each leg of the call. If a system does not support REFER, removing it from the advertised methods may force some platforms to use INVITE with Replaces as a temporary workaround.

Next, verify that the new INVITE preserves the Refer-To and Referred-By values and that 202 Accepted and NOTIFY messages reach the system that initiated the transfer. Check message timing too, particularly whether a BYE arrives before the final NOTIFY. If callers hear silence instead of ringing, check REFER support and the handling of 180 Ringing and 183 Session Progress responses, which provide call-progress updates.

Also review firewall rules to ensure all required signaling addresses are allowed, and confirm that destination numbers use the format expected by the next system.
Finally, test internal and external transfers separately, including both blind and attended transfers across desk phones, softphones, and mobile devices. Comparing the results helps identify which system or network connection is causing the failure.

Call transfer failures between your phone system, carrier, or cloud platform can be difficult to diagnose. Our team can capture and analyze SIP traffic, identify where the handoff breaks, and help get your calls transferring reliably. Contact us to start troubleshooting.

When a transferred call drops: How to troubleshoot SIP interoperability issues

Editor November 11, 2026

Transfer failures between phone systems usually come down to a handful of common issues. One system may not support the transfer method, SIP headers may get changed along the way, progress messages may not come through, or a firewall may block the signaling. Each issue leaves clues in the SIP logs, making it easier to identify what’s going wrong and find the right fix.

How a SIP transfer works

A SIP call transfer involves three parties: the transferor, who initiates the transfer; the transferee, whose call is being moved; and the target, who receives the call.

Most transfers use the SIP REFER method, defined in RFC 3515 (The Session Initiation Protocol REFER Method). This RFC defines how one SIP device can ask another to make a new request, such as starting a call to a different destination. The destination is included in the Refer-To header, while the Referred-By header identifies who requested the transfer.

The receiving system then sends a new INVITE, the SIP method used to initiate a call, to the target. It reports the call’s progress through NOTIFY messages, which communicate updates such as whether the new call is ringing or has connected.

The process depends on the type of transfer. A blind transfer sends the call to the target immediately, without first checking their availability. An attended transfer allows the transferor to call the target first and confirm they are available before completing the handoff. It uses the Replaces header, defined in RFC 3891 (The SIP Replaces Header), to identify the existing call that the new call should take over.

For a broader look at how these mechanisms work together, RFC 5589 (Session Initiation Protocol Call Control – Transfer) describes recommended practices and call flows for implementing SIP transfers, including blind and attended transfers.

Where interoperability breaks down

SIP transfer failures usually fall into a few common categories. The first is support mismatch: not every phone system or carrier supports REFER. Microsoft Teams Direct Routing documentation provides an example of how platforms handle this, listing a fallback order of REFER, INVITE with Replaces, and then an internal transfer method that the session border controller (SBC), which manages SIP traffic between networks, cannot see. These fallback methods can behave differently, sometimes leaving callers unable to hear the phone ringing while waiting for an answer.

Header handling is another common issue. A REFER request may not contain all the information needed to route the new call, so Microsoft expects the SBC to preserve the Refer-To and Referred-By headers when creating the new INVITE. That INVITE must go back to the platform’s SIP proxy rather than directly to the telephone network. Rewriting the headers or routing the INVITE elsewhere can break the transfer.

Missing progress messages can also cause failures. The receiving system should respond to REFER with “202 Accepted” and send NOTIFY messages to report progress. If these messages never reach the initiating system, it may time out. If a BYE message, which ends an established call, arrives too early, the original call can drop before the transfer completes.

Firewall rules add another potential obstacle. REFER requests may arrive over new TLS connections from any of the platform’s signaling addresses. Firewalls that allow only specific addresses can block these requests, even when other SIP traffic works normally.

Finally, carrier behavior and platform updates can introduce unexpected problems. A 481 Call/Transaction Does Not Exist response means the receiving system can no longer find the referenced call or transaction. During an attended transfer, this can happen when the transferor’s temporary call to the intended recipient (known as a consultation call) stays on hold long enough for a carrier device to expire it.

Platform changes matter too. In June 2026, Microsoft changed its blind-transfer behavior so its side ends the original call as soon as the SBC accepts the transfer, without waiting for the final result. Configurations that worked under the previous behavior may therefore need to be reviewed.

Practical troubleshooting checks

Start by identifying the transfer type (blind or attended), its direction, and which system receives the REFER request. Capture SIP traces of both a failed and successful transfer using SBC logs or a packet capture, then compare the messages to find where they differ.

Check whether REFER is listed in the Allow header on each leg of the call. If a system does not support REFER, removing it from the advertised methods may force some platforms to use INVITE with Replaces as a temporary workaround.

Next, verify that the new INVITE preserves the Refer-To and Referred-By values and that 202 Accepted and NOTIFY messages reach the system that initiated the transfer. Check message timing too, particularly whether a BYE arrives before the final NOTIFY. If callers hear silence instead of ringing, check REFER support and the handling of 180 Ringing and 183 Session Progress responses, which provide call-progress updates.

Also review firewall rules to ensure all required signaling addresses are allowed, and confirm that destination numbers use the format expected by the next system.
Finally, test internal and external transfers separately, including both blind and attended transfers across desk phones, softphones, and mobile devices. Comparing the results helps identify which system or network connection is causing the failure.

Call transfer failures between your phone system, carrier, or cloud platform can be difficult to diagnose. Our team can capture and analyze SIP traffic, identify where the handoff breaks, and help get your calls transferring reliably. Contact us to start troubleshooting.

When should a business retain or delete Microsoft 365 documents?

Editor November 9, 2026

Every document a business keeps carries both a cost and a risk. Keep records too briefly and the company may breach a legal requirement or lose evidence it needs. Keep everything forever and storage grows, searches slow down, and old content becomes a liability in a lawsuit or a data breach. Microsoft Purview lets administrators decide by rule what to keep, what to delete, and when. But deciding what to keep is only part of the equation; businesses also need a way to recover data when it is lost.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

A practical guide to document life cycle management in Microsoft 365

Editor November 9, 2026

Many businesses assume that anything stored in Microsoft 365 is both safe and permanent. In reality, content is kept only for as long as the applicable retention settings require, and keeping information available is not the same as ensuring it can be recovered if something goes wrong. Understanding this distinction helps prevent costly surprises, whether a business needs to retrieve an important document or ensure that outdated content is properly removed.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

Microsoft 365 retention explained: Policies, labels, and knowing when to let data go

Editor November 9, 2026

Microsoft 365 will keep or delete content automatically based on retention rules configured by administrators. Retention policies and labels turn legal, regulatory, and business requirements into settings that run quietly in the background. Getting them right means understanding how the rules interact, when deletion is appropriate, and why retention is a different thing from backup.

What retention rules actually do

Microsoft Purview provides the tools administrators use to control how long Microsoft 365 content is kept and when it should be deleted. It offers two basic retention actions: retain content so it cannot be permanently deleted, and delete it permanently. Combined, these produce three possible outcomes: retain only, delete only, or retain for a set period and then delete.

Content stays where it already lives, so people can continue working normally. If someone edits or deletes an item subject to retention, Microsoft quietly preserves a copy in a protected location, such as the Preservation Hold library for SharePoint and OneDrive or the Recoverable Items folder for Exchange mailboxes. Note that the Preservation Hold library counts toward a site’s storage quota, so retention can increase storage requirements.

Retention policies vs. retention labels

Administrators use two main tools to put retention requirements into practice: retention policies and retention labels. The difference is largely a matter of scope.

A retention policy applies the same set of rules to a broader location, such as a SharePoint site, Exchange mailbox, or Teams location. A retention label, by contrast, applies rules to an individual item, such as a document, folder, or email. This is useful when different records within the same location need different retention periods or treatment.

Labels also offer more flexibility in how retention periods are triggered. The clock can start when a label is applied or when a specific event occurs, such as an employee leaving or a contract expiring. They can also require a disposition review before content is permanently deleted.

The two tools often work together: policies establish the default retention rules for a location, while labels provide more specific instructions for individual records that need different treatment.

Setting retention periods based on requirements

Once retention policies and labels are in place, the next step is deciding how long content should be kept. Those periods should reflect legal, regulatory, and contractual obligations, not administrative convenience. For example, certain records may need to be retained for seven years under requirements such as the Sarbanes-Oxley Act. Tax, employment, healthcare, and client agreements may impose different timelines, so legal or compliance advisors should help determine the appropriate periods before retention settings are applied.

Beyond those requirements, avoid keeping content indefinitely without a clear business reason. Unnecessary records increase storage and e-discovery costs, expand the amount of data exposed in a breach, and make it harder to find relevant information.

How Purview resolves conflicting rules

A document or email may be covered by several retention policies and labels at the same time. When their instructions differ, Microsoft Purview uses four principles to determine what happens: retention takes precedence over deletion, the longest retention period wins, an explicit deletion instruction from a label takes precedence over an implicit deletion instruction from a policy, and the shortest deletion period applies among the remaining eligible rules.

For example, if an email is subject to a policy that deletes content after three years and a label that retains it for five years, Purview keeps it for five years before deletion. An eDiscovery hold takes precedence over these retention settings, although Microsoft advises against using holds for long-term life cycle management.

New retention settings can take up to seven days to take effect, so test them on a small group of sites or mailboxes before applying them across the organization.

Retention is not a backup

Retention policies and labels help organizations control how long Microsoft 365 content is kept for governance and compliance, but they are not designed for full data recovery. They do not create independent backup copies or point-in-time restore options. Recovering a lost folder may require searching protected locations or running an eDiscovery search rather than simply clicking Restore. More importantly, retention preserves content as users change or delete it; it does not provide a clean copy from before an incident such as ransomware or a mass deletion by a compromised account.

Recycle bins offer some short-term recovery, but their protection is limited. Deleted SharePoint and OneDrive items remain recoverable for about 93 days across both stages, while Exchange retains deleted items for 14 days by default, extendable to 30. Confirm these settings in your own tenant, as defaults may change. For more reliable recovery, organizations need an independent backup of their Microsoft 365 data, whether through Microsoft’s own backup service or a third-party solution.

A practical starting point

Start by identifying the main content types, mapping each to its legal, regulatory, or business requirements, and creating a small set of retention policies before introducing labels for more specific needs. Test the settings on one site or mailbox group, review the results with legal or compliance advisors, and expand gradually.

Take particular care with Preservation Lock: once enabled, it prevents anyone, including administrators, from modifying or removing the protected policy. Document the reasoning behind each decision and review the plan annually to keep pace with changing regulations and business needs.

Not sure how long your business should keep its Microsoft 365 documents, or whether your data is truly recoverable? Our team can review your retention settings, align them with your compliance needs, and set up backup that fills the gaps. Reach out to get started.

How dependencies shape business application availability

Editor November 6, 2026

Cloud application outages can stem from failures in supporting services and infrastructure. A failed sign-in may result from an authentication service outage, an inaccessible website from a DNS or network issue, and an unconfirmed order from a database or payment processing failure. Mapping these dependencies in advance and deciding how the application should respond when they become unavailable can prevent individual service failures from disrupting essential business operations.

Understanding hard and soft dependencies

In cloud application architecture, dependencies can be classified as hard or soft, depending on how essential they are to an application’s core functionality. A hard dependency is a service or component the application cannot function without. A soft dependency is one that can become unavailable without stopping the application’s essential functions, although some features may be limited or temporarily unavailable.

Applications should be designed to keep their essential functions running even when a supporting service becomes unavailable. For example, an online store should still allow customers to place orders if its product recommendation service goes down. Customers may lose personalized suggestions, but they should still be able to browse products and complete purchases.

Four dependencies that affect cloud application availability

There are four critical dependencies that require careful planning and management: identity providers, DNS, third-party APIs, and background processing systems.

Identity providers

Single sign-on makes it easier for employees to access multiple applications with one set of login credentials. However, if the identity provider responsible for verifying those credentials becomes unavailable, employees may lose access to applications that are otherwise working normally. Employees who are already signed in may also lose access when their login sessions expire.

To reduce disruption, set session durations carefully so employees are not all forced to sign in again during a brief service outage. Balance this with security requirements. Also, maintain a small number of emergency administrator accounts that can be accessed independently of the main sign-in service. Protect these accounts with strong multifactor authentication and test them regularly to ensure they work when needed.

DNS

DNS (Domain Name System) helps users and applications find websites and online services by translating domain names into the addresses computers use to connect. If DNS stops working, users may be unable to reach websites even when the servers hosting them are still running. Applications may also lose access to other services they depend on.

To reduce this risk, consider using a backup DNS provider for important domains so another provider can take over if the primary one fails. Set DNS record update times (known as time-to-live or TTL values) to allow changes to take effect within an appropriate timeframe. Secure your domain registrar account, keep track of renewal dates, and make sure designated team members know how to update DNS records during an emergency and where to access the required credentials.

Third-party APIs

Payment processors, shipping services, messaging platforms, and mapping tools often rely on external services to provide essential features. If one of these services responds slowly or stops working, the application may struggle to complete tasks that depend on it. A slow response can be particularly disruptive because the application may continue waiting, tying up resources that other users need.

To limit the impact, configure time limits so the application does not wait indefinitely for an external service. Limit the number of automatic retries and use a circuit breaker, which temporarily stops requests to a service that is repeatedly failing. Where possible, provide an alternative result rather than leaving users waiting.

For example, a travel booking platform could display previously retrieved hotel availability information while a hotel provider’s API is temporarily unavailable, rather than leaving users waiting for the page to load. Keep these alternatives simple and avoid complicated workarounds that introduce additional dependencies or potential points of failure.

Background processing

Queues and background jobs let applications handle tasks without making users wait. For example, an employee management system can save a leave request immediately while processing approval notifications or updating payroll records in the background. However, if a service needed to complete these tasks becomes unavailable, unfinished work can pile up. Repeated retries can make the backlog worse and overwhelm the service when it recovers.

To limit disruption, set limits on automatic retries and the number of tasks waiting in a queue. Use a dead letter queue (DLQ), a separate holding area for tasks that repeatedly fail, so they can be investigated and processed later without blocking other work. Keep essential user-facing functions running independently of background tasks, and identify which jobs must be completed promptly and which can safely wait.

Map the chain and rehearse the failures

For each critical application, identify the services it relies on, then determine which services are essential for the application to function and which can become unavailable without stopping its core features. Document what users would experience if each service failed and test whether the application can continue operating under those conditions.

A common mistake is failing to identify which application functions are essential to business operations or assuming they will continue working when a supporting service fails without testing them. Businesses that rely on Software-as-a-Service (SaaS) products should also ask vendors about their service dependencies, outage procedures, and availability commitments, and include this information in vendor assessments.

If you’re unsure how exposed your business applications are to a single failing service, we can help. Our team can map your critical dependencies, identify the weak points, , and help you plan how to keep essential application features available during an outage. Contact us to start the review.

Website Management for Small Business Owners

Full-service, pay-as-you-go WordPress websites, from design and content to SEO and Google Ads management for an affordable monthly price.

Learn more about our website management services for small businesses.

Search
Archives