Overview
When the same technology problem affects many or all employees, stop treating it as an individual workstation issue. The fastest path is to establish scope, identify the shared dependency, check provider and infrastructure health, and avoid repeated user-level changes that cannot fix a common failure.
Why this happens
Office-wide problems often originate from shared internet service, DNS, firewall, wireless infrastructure, identity provider, Microsoft 365, Google Workspace, line-of-business applications, shared storage, licensing, power, or a vendor outage.
Before you begin
- Record the first known time the problem started.
- Identify at least two affected users and, if possible, one unaffected user or location.
- Identify what changed immediately before the outage.
- Do not make multiple infrastructure changes at once.
Click-by-click troubleshooting
Step 1: Define the scope precisely
Action: Ask whether the issue affects all employees, one department, one floor, one Wi-Fi network, one application, one location, or remote users as well.
Why this matters: Scope identifies which shared dependency is common to the affected users.
What to look for: Look for boundaries such as only Wi-Fi users, only Microsoft 365 users, only one building, or only one application.
Expected result: You should be able to describe the smallest affected group and the largest unaffected group.
Step 2: Identify the shared dependency
Action: Map the affected function to its common dependency: internet, DNS, identity, cloud service, network share, firewall, wireless, printer server, or vendor application.
Why this matters: An office-wide symptom usually has a shared cause. Testing individual computers repeatedly wastes time.
What to look for: Determine what every affected user depends on that unaffected users do not.
Expected result: You should have one or two likely shared layers to test next.
Step 3: Test one representative device
Action: On one affected computer, test a known website, the affected business service, and another unrelated business service. Record exact errors rather than testing every employee's device.
Why this matters: A representative test gives evidence without multiplying unnecessary changes across the office.
What to look for: Determine whether internet, DNS, authentication, and the specific service fail together or separately.
Expected result: You should narrow the outage to a shared network, identity, or application layer.
Step 4: Check provider service health
Action: If the affected service is Microsoft 365 and you are authorized, open the Microsoft 365 Admin Center, then select Health > Service health and review active incidents and advisories. For Google Workspace, open the Google Admin console and review the available service-status or alert information for the affected service. For an internet provider or line-of-business application, open the provider's approved administrative status page or support portal. Use a public status site only as supporting evidence.
Why this matters: A confirmed provider incident should not trigger local configuration changes.
What to look for: Look for an active advisory or incident matching the service, region, and start time.
Expected result: Either a provider incident explains the outage, or local/shared infrastructure remains in scope.
Step 5: Check shared network reachability without changing equipment
Action: On one affected Windows computer, select the network icon on the taskbar and confirm the expected connection. Then open Settings > Network & internet and review the active Wi-Fi or Ethernet connection. Open Command Prompt, run ipconfig, test the default gateway, test an approved external IP address, and run nslookup www.microsoft.com or another approved hostname.
Why this matters: These read-only tests can separate local network, internet, and DNS failure without rebooting infrastructure.
What to look for: Look for missing addressing, gateway failure, external reachability failure, or DNS failure shared across affected devices.
Expected result: You should identify whether the common failure sits at local network, internet, or DNS level.
Step 6: Check identity and authentication scope
Action: If users can reach websites but cannot sign into a shared cloud service, open a private browser window and test the organization's primary sign-in portal. If you administer Microsoft 365, open the Microsoft 365 Admin Center and review Health > Service health. If you administer Google Workspace, open the Google Admin console and review relevant alerts or service-status information before changing user accounts.
Why this matters: Authentication outages can make many unrelated applications appear broken at the same time.
What to look for: Look for widespread sign-in errors, MFA failures, token errors, or provider advisories.
Expected result: You should know whether identity is the common failure point.
Step 7: Preserve the timeline and escalate the shared outage
Action: Record start time, affected scope, representative errors, service-health results, network tests, and any recent approved change. Send one consolidated escalation instead of separate tickets for every employee.
Why this matters: A clean outage timeline speeds diagnosis and prevents duplicate or conflicting repair actions.
What to look for: Include what works, what fails, when it started, and whether a provider or infrastructure change coincided with the event.
Expected result: IT or the vendor should receive enough evidence to act on the shared failure immediately.
What to look for
- Only one office or SSID affected: local infrastructure boundary.
- Internet works but sign-in fails for everyone: identity or cloud service boundary.
- Provider health shows an incident: avoid unnecessary local changes.
- Gateway or DNS fails for many devices: shared network service problem.
- A recent approved change matches the outage start time: include it in escalation.
When to stop
When to contact IT
Contact IT immediately when multiple employees or a business-critical service are affected. Provide the outage start time, scope, locations, representative errors, service-health findings, network test results, and recent changes. Treat security alerts, ransomware indicators, or suspicious authentication failures as a security incident rather than routine troubleshooting.
Need help with this issue?
J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.
Contact J3 Systems GroupAuthoritative references
Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.