Support restored connectivity by removing duplicate, stale, or conflicting Wi‑Fi profiles so devices retained only the correct campus/corporate SSID and by addressing profile settings and driver/firmware state. Technicians removed obsolete profiles via Settings → Network & Internet → Wi‑Fi → Manage known networks (Forget) or used MDM/enterprise tools when the GUI did not expose profiles; several onboarding/fresh‑device cases resolved after connecting to IU_Study first then deleting and re‑adding the corporate profile (CPG/CPG‑Corp/IU‑Internal). In some incidents the incorrect profile was removed during remote support sessions over Microsoft Teams; in others devices were temporarily put on wired Ethernet so support could forget networks and reconnect to the corporate SSID. Where forgetting profiles did not prompt reauthentication, support ran group policy and account sync actions (examples observed: gpupdate /force, Windows account synchronization) or recreated the wireless profile; reauthentication sometimes required entering the username in the campus‑specific format (firstname.lastname or UPN) because NPS handled different username formats. Multiple incidents were traced to credential desynchronization after remote password changes; those stopped after an admin reset or after the user reset their password onsite so workstation and domain credentials resynchronized. RADIUS/NPS and AD logs frequently recorded “incorrect password”; technicians verified NPS username‑format handling and WLAN authentication group membership when logs or group membership mismatches indicated failures. Repeated failed authentications had caused temporary NAC bans in at least one case; removing stale local profiles halted repeated attempts and cleared the ban. eduroam cases that resisted deletion or hid the credential prompt required re‑provisioning or recreating the profile via device management tools or testing by adding eduroam on another device. Vendor driver and firmware updates or WLAN module replacement resolved multiple Windows cases (examples: Lenovo System Update, Dell Command Update); some incidents producing BSODs and memory dumps also resolved after updating drivers or replacing faulty WLAN hardware. Fresh‑device keyboard‑layout mismatches produced incorrect password entry until corrected. In one ThinkPad a disabled per‑profile “connect automatically” toggle prevented association and enabling that setting (with available system updates applied) restored connectivity.

Technicians resolved incidents by repairing or replacing faulty Wi‑Fi drivers, adapter firmware and occasionally the system BIOS, or by reinitializing/replacing the wireless adapter. Vendor update utilities (Dell SupportAssist full system scan, Dell Command | Update, Lenovo System Update) and BIOS updates were commonly applied over a wired connection (USB‑C Ethernet adapters or mini‑docks) when the wireless interface was unreliable; technicians also connected systems to AC power before running vendor update tools in multiple cases. Where the adapter entry had vanished or appeared disabled, removing the Wi‑Fi driver in Device Manager forced Windows to reinitialize the device; multiple restarts or a full power cycle were sometimes required. Restoring domain/VPN connectivity allowed Group Policy and vendor/OS updates to run with elevated privileges and reactivated interfaces that reported “Updates paused by organization.” Frequency‑specific failures (2.4 GHz vs 5 GHz) were resolved by driver/firmware/BIOS updates or by replacing devices when antenna/hardware faults were suspected; testing on personal networks and comparison with other clients helped isolate device‑specific band/antenna issues. A recurring class of incidents involved Intel Wi‑Fi 6 AX201 with netwtw08.inf v21.10.2.2 where Tx retries and Tx confirmation errors (600) correlated with gateway/DNS failures and intermittent disconnects; replacing or updating the driver/firmware restored reliable connectivity in those cases. Application‑level impacts were observed: Microsoft Teams call dropouts occurred in multiple cases (notably during calls with camera/microphone active), and unstable connectivity blocked sign‑in flows (Okta Verify and support pages became inaccessible) on replacement/new machines. In a few incidents a problematic VPN client worsened throughput and disabling it reduced drop rates. Local OS recovery tools failed in at least one case (SupportAssist OS Recovery produced a BSOD with Diagnostics Error 0000 and Validation 109120); remediation via vendor update tools over a wired connection or device replacement restored corporate SSID access. When driver/firmware repairs failed to produce a stable adapter, technicians used driver reinstallation and, in some cases, a clean OS reinstall (Fresh Start) or full device replacement to restore reliable wireless connectivity. Some tickets contained no confirmed fix and recommended replacement when updates could not be applied. Service tags, screenshots and Device Manager logs were used to triage hardware vs driver causes.

Support outcomes attributed this symptom set to multiple distinct causes across client and network layers; observed resolutions included the following.

After required WLAN configuration updates, NAC/Portnox or AD/WLAN group corrections and propagation, completion of Intune/Jamf/Azure AD enrollment, credential/authenticator resynchronization, or OS/supplicant recovery (and when necessary, hardware replacement), affected endpoints regained access to corporate SSIDs and associated SSO/MFA functions.

Support cleared stale saved SSID profiles and, in many cases, forgetting and rejoining the SSID restored captive‑portal sign‑in and Internet access. Corporate Wi‑Fi and eduroam access succeeded after users authenticated with the correct account identifier and credential type (commonly the institutional email address with the Okta/Microsoft password), supplied the full username@realm for eduroam, or when required Okta/wireless group membership or administrator‑issued WLAN authorization was present. Repeated sign‑in failures were resolved by renewing expired Active Directory passwords or by presenting a supported Okta MFA factor when misregistered/unsupported factors were in use. Windows credential sequencing issues were traced to Windows Hello/PIN ordering and cleared when the correct credential sequence was used. Several eduroam and corporate SSID failures were resolved after installing or explicitly trusting the SSID certificate or accepting the network certificate presented by the SSID. Mistyped passwords caused by incorrect keyboard layouts were corrected after re‑entry with the proper layout. A Windows 11 sign‑in case regained network access after the device connected to the correct campus SSID at the sign‑in screen, which restored a prior VPN fallback path. L2TP VPN failures and missing VPN UI icons were observed alongside Wi‑Fi authentication failures; these VPN symptoms resolved in cases where the device obtained a working network path (for example by rejoining the correct SSID or using Ethernet) or after Wi‑Fi authentication and credentials were corrected, allowing the L2TP handshake to complete. Network‑separated AirPrint failures were attributed to VLAN isolation and printing succeeded when the client was on the same VLAN as the printer or when the printer was added by IP from the student/Study network. Initial on‑site notebook setups sometimes failed on first attempts but later connected. Legacy CPG/CP access had been disabled for some Apple devices after the CP network shutdown; affected devices were redirected to Study or alternative campus SSIDs such as IU‑Internal. Peripheral display/dock symptoms seen during wireless troubleshooting were sometimes unrelated to Wi‑Fi and were resolved after installing or enabling vendor display software (for example DisplayLink). For third‑party or unmanaged SSIDs, support documented that the network was not managed by the institution and advised external users to use the institutional guest SSID (IU‑Guest).

Investigations across incidents identified four recurring root causes and their remedies. 1) Cabling and VLAN mispatch: wall sockets or monitor/display cabling were sometimes unpatched at the patch panel, terminated to the wrong switch port, or assigned to an unexpected VLAN; correcting patch‑panel terminations and assigning the switch port to the expected VLAN (for example VLAN200 on switch BHF1CS18) restored wired network and display connectivity and allowed local devices and new client machines to register. 2) SSID/endpoint association and user‑segment behaviour: several cases involved client devices simultaneously associating to multiple SSIDs (notably IU Study and IU Guest) or being directed to the wrong SSID, causing in‑room roaming and loss of service; stability was restored when devices used the expected SSID and AP, and Meraki SSID/SSID‑assignment and appliance settings were reviewed to prevent overlapping associations. 3) Event/port restrictions and capacity limits: some wired ports were reserved or constrained to projector/staff VLANs (CPG‑Net) and not available to external users; capacity analysis also showed IU‑Guest imposed an effective per‑user upload limit (~30 Mbit/s) while a venue shared a single 1 Gbit/s upstream, so creating a temporary private WLAN did not increase aggregate upstream capacity — these constraints were documented for event planning. 4) Endpoint and AP placement or device configuration: certain endpoints (for example Viewneo digital‑signage boxes) lost connectivity after AP or wall‑socket moves and required local device reconfiguration (a technician used a USB console to toggle the device’s network/Wi‑Fi setting) and mispatched wall sockets were flagged; other incidents were resolved by changing physical AP orientation or mounting position, which noticeably strengthened signal and reduced disconnections. Each incident was closed after the specific cause was identified (mispatched cabling or wrong VLAN, overlapping SSID associations, restricted/reserved port or upstream capacity limit, endpoint reconfiguration, or AP placement) and the corresponding remediation or documentation was applied.

Problems were resolved by restoring the phone’s hotspot/tethering state and repairing host‑side connectivity. On iPhone cases enabling Personal Hotspot and toggling the 'Allow Others to Join' state caused the device to expose the SSID and the Personal Hotspot Wi‑Fi password; verifying or resetting that password on the phone and entering the correct key on the laptop completed the connection. In Android cases Bluetooth tethering was restored after removing the phone from the PC’s Bluetooth device list and re‑pairing. In one instance toggling Bluetooth off and re‑enabling Wi‑Fi on the PC caused the Mobile Hotspot option to become enabled when restarts and hard power‑offs had not helped. Several incidents involved hotspot SSIDs that were transiently undiscoverable and later became visible; support confirmed private phone hotspots behaved like normal Wi‑Fi networks and required no service‑side enablement. In this environment iPhones did not support Bluetooth tethering, so hotspot use was limited to Wi‑Fi (WLAN) or USB tethering. Some iOS personal‑hotspot cases showed frequent disconnects where laptops did not auto‑reconnect and required re‑entering the hotspot Wi‑Fi password; teams investigated eSIM‑capable laptops and mobile routers as alternative approaches but no definitive resolution was recorded.

Incidents were traced to failures or misconfiguration across campus WLAN, authentication services, controller‑to‑AP communication, and WAN/uplink infrastructure. Remediations that restored service included: restarting failed RADIUS/authentication server processes and clearing authentication caches or temporary login blocks; resolving controller‑to‑AP communication faults and performing controller restarts; applying vendor firmware fixes or configuration changes and power‑cycling or replacing unstable APs; restoring or provisioning network uplinks where physical path/uplink failures existed; and reverting AP security‑mode changes (for example reversing WPA3‑only profiles) to restore legacy client visibility. In at least one case APs were adjusted to permit required authentication key pairs after controllers were observed rejecting specific credential exchanges. Corporate SSID/profile migrations or replacement profiles were pushed to endpoints where profile mismatch was a factor. Client‑side remediation rarely restored connectivity while central infrastructure was unavailable, though a subset of Windows clients recovered after UI‑level Wi‑Fi steps and reboot; macOS clients frequently refused association until central services were repaired. Networked printers sometimes required additional profile or network remediation after Wi‑Fi resumed. Users commonly relied on fallback networks (iu‑guest, iu‑study, iu‑internal, eduroam), mobile hotspots, or VPNs during outages. Some site incidents had no recorded central action and resolved spontaneously after hours; confirming user group membership (for example IU‑ZZ‑OK‑ASS‑CPGCorpWireless‑All‑Access) did not always identify the cause.

Investigations repeatedly identified campus-side network or upstream faults rather than client VPN failures. Short transient outages typically cleared after campus network teams intervened (recoveries ~5–20 minutes); longer or recurring incidents commonly traced to unstable or capacity‑limited upstream links (notably cellular 5G backhaul and third‑party ISPs). At sites using 5G backhaul, parameter and configuration adjustments improved stability and teams provisioned additional or replacement uplinks where necessary. Capacity‑related slowness was mitigated by adding internet uplinks, tuning switch/network configurations to reduce congestion, and applying per‑device bandwidth limits to identified high‑usage clients. A misconfigured traffic‑shaping rule on the student/guest WLAN in Hannover caused a multi‑hour outage and was corrected. Location‑specific faults were resolved after Ekahau site surveys and AP radio/configuration changes at multiple APs (examples: AP03/Aegidiimarkt, AP09/Media Lab, AP13, AP14, AP07, AP05, AP02); third‑party AP deployments required on‑site inspection and coordination with external providers to isolate provider‑side faults. Troubleshooting combined campus monitoring, packet‑loss checks, traceroutes, DNS and upstream‑reachability tests, WLAN coverage maps, and DHCP/RADIUS verification; some sites showed no detectable local configuration faults and remained under monitoring while upstream conditions cleared. Investigations also identified cases where the WLAN controller treated rapid roaming between IU‑Guest and IU‑Study as atypical client behavior and repeatedly blocked those clients, and other cases where devices regained Internet only when connected from a different campus — indicating device‑specific behavior or localized upstream/path issues. Support routinely requested exact incident timestamps, room or visible AP ID and client MAC addresses for reproducibility, but users frequently could not supply MACs which limited root‑cause isolation. Recorded client‑side remediation included removing/forgetting overlapping SSID profiles, restarting devices and reconnecting to the appropriate corporate SSID; a minority of users could not switch SSIDs where credentials were missing. Secondary impacts across incidents included severe printing delays, VoIP/Twilio audio drops and monitoring indicators fluctuating to red/yellow. Several fixes were temporary; permanent resolution frequently required provisioning a new uplink or changing upstream providers.

The issue was resolved by changing the Dell Optimizer power profile: Dell Optimizer's Power/Battery performance was set to "Ultra Performance" and any pending Windows Updates were installed. After applying the higher-performance power profile and updating Windows, network throughput and Microsoft Teams call quality returned to expected levels.

Outages were resolved by addressing the specific underlying cause identified during troubleshooting. Power and connectivity issues returned service after APs were reconnected to powered switchports or faulty cabling/patching was replaced and building power faults were corrected by facilities. APs that were long-term offline or marked “Ignored” in the controller were re‑provisioned or re‑set up when the devices were present and inventory/documentation was corrected. Hardware faults and reboot loops were handled by onsite replacement or specialist escalation. AP‑to‑WLAN‑controller and controller‑communication problems were diagnosed with collected device details and forwarded to infrastructure teams for remediation. Capacity and performance problems were investigated using site surveys and monitoring tools (Ekahau) and addressed by traffic‑shaping, link adjustments, and targeted AP replacement where sustained packet loss or throughput degradation occurred. Incidents where large numbers of failed authentications or wrong‑credential retries generated high traffic and blocked client access were remediated after coordination with authentication/identity teams to clear or stabilize authentication sessions, correct credential/profile configuration, and reduce offending client retries. Temporary mitigations recorded in tickets included restarting APs and client devices, using alternate SSIDs or rooms, relocating users while repairs were carried out, and on‑site verification to distinguish client‑side faults from network outages.

Investigations repeatedly localized these incidents to the network path (home router, local Wi‑Fi client configuration, ISP upstream, or VPN) rather than to camera hardware or application software alone. In multiple cases switching the client to an alternate path — for example a mobile hotspot or a wired Ethernet connection — immediately restored media and call continuity. Physically moving the device closer to the router or switching Wi‑Fi band stabilized media in several incidents. Where the home network was confirmed at fault, correcting router configuration (one recorded case involved a misconfigured second Fritzbox causing 2.4/5 GHz and dual‑router issues) resolved blocked or failed data transfer; other faults required escalation to the ISP or VPN vendor. Vendor driver and firmware update utilities (for example Lenovo System Update, Dell Command Update / SupportAssist) were used when client Wi‑Fi drivers or tethering appeared suspect, although administrative restrictions prevented applying updates in some cases. Attempts to clear application caches were recorded (Outlook cache cleared for unresponsiveness; Chrome cache/cookies cleared in a VoIP case) but did not reliably resolve incidents where packet loss was present; support evidence included delayed call logs consistent with packet loss. Some device‑specific incidents (notably on macOS) showed browser traffic recovering while native apps remained slow; these remained unresolved in ticket records and were attributed to a device‑specific Wi‑Fi path problem rather than household connectivity. Recorded outcomes varied: immediate network‑path changes reliably produced short‑term recovery, while persistent issues required network‑side configuration changes or vendor escalation; a subset of cases reported that Teams or Vonage calls caused complete connection drops or broad system slowdowns prior to remediation.

Multiple distinct root causes were identified; each remediation correlated with symptom resolution on affected machines:

Across tickets, technicians documented providing the NCSI suppression registry command as a mitigation and observed that monitoring after the change sometimes showed no further incidents. Root causes therefore varied between Windows network‑status probes (NCSI), WcmSvc state handling, router compatibility/DNS interactions on consumer home routers, outdated client drivers/firmware, and at least one faulty client device.

The request documented the protocol limitation and the rationale for switching to TTLS-PAP (TTLS-PAP would allow the RADIUS backend to receive plaintext credentials). The change was identified as a configuration/protocol change with significant security implications because TTLS-PAP would expose plaintext passwords to backend systems. The ticket recorded those constraints and flagged the need for infrastructure/RADIUS and security review rather than applying an immediate configuration change.

Support staff confirmed that Eduroam was managed by the university infrastructure team. They advised that public-library locations were not yet supported by the university-provided Eduroam service at the time of the inquiries and routed the request about public-library rollout to infrastructure; infrastructure committed to communicate availability when it changed. For individual users, staff confirmed Eduroam access was automatically provisioned for accounts with an @iu address, verified/enabled the requester's account (no approval required), and had the requester test connecting to the Eduroam SSID using their @iu credentials.

The incident was resolved by provisioning five portable 5G routers (Cradlepoint and consumer 5G units) with prepaid high‑volume SIMs, performing an on‑site RF/signal survey to identify best router placement, and configuring uplink failover and SIM‑based load distribution across devices. A local LAN file‑share (LAN‑only NAS / SMB) was deployed so large files were exchanged without consuming WAN bandwidth, and QoS limits were applied on the routers to prevent any single user from saturating mobile uplinks. The temporary SSIDs and NAT were preconfigured and monitored during the event to adjust placement and redistribution of clients as needed.

On-site assessments identified missing, disconnected, improperly mounted or unpowered access points, routers and switches, and technicians verified physical placement, mounting, power and patch-panel connectivity. Incidents were resolved by re-cabling, reconnecting and remounting devices, replacing or re-seating power supplies, and verifying wall outlet and patch-panel port power when devices would not power on. When inventory devices were present but not provisioned for the building, technicians either configured the APs for the site or arranged for pre-configured replacement units; unsuitable spare models were ordered and shipped or preferred spares were retrieved from inventory and transported to the site to coincide with other visits. Deployments ranged from prioritized single-room setups to multi‑AP rollouts (examples included single-room installs and 11‑AP deployments across reception, administration and office spaces). For coverage gaps or areas that never had Wi‑Fi, teams documented the absence of building plans, coordinated schedule access across rooms (including multi‑day visits when required) and captured RF planning requirements; Ekahau site surveys were used when site measurements and AP repositioning were required. Physical work also included securing mounting panels and performing requested desk hardware setup (monitors, docking stations, HDMI). Tickets were completed after installation, configuration or handover and confirmation that expected wired or wireless connectivity and signal coverage had been restored.

The issue was resolved by connecting the Windows PC to the new home SSID and authenticating with the router's new Wi‑Fi password via the Windows network UI. After the PC joined the new network, IU remote services functioned normally and the ticket was closed following user confirmation.

The organization procured Portnox to replace the Windows NPS RADIUS service and established a migration plan to move the CPG‑Corp SSID to certificate‑based authentication for Windows 10/11 and macOS clients. Certificate revocation was handled by leveraging the internal CA (cpg.int) CRL as the revocation source during the design and testing phases. Stakeholders were identified and coordination meetings were held to manage the phased migration; eduroam remained on its existing separate RADIUS infrastructure.

The situation persisted as a policy and funding decision rather than a technical fault: existing island deployments (Click and Share in Hamburg and EZcast devices in Berlin) were retained to provide limited wireless presentation capability, and the broader campus‑wide rollout had not been approved because cost/approval was withheld. The request was escalated to the academic council/cost‑approval process for consideration; until approval, rooms continued to rely on HDMI or the local island devices.