Support restored Company Portal delivery and corporate app installation by addressing enrollment/assignment, account mapping, service availability, and connectivity anomalies. Frequently observed resolutions included: restarting the Microsoft Intune Management Extension service or rebooting devices, after which the portal and managed Office apps typically appeared or auto‑installed within a few hours; manually installing Company Portal from the Microsoft Store when it was already marked distributed; connecting devices to a reliable network (ethernet or corporate Wi‑Fi) and leaving them online until provisioning completed; reactivating or reassigning Company Portal when administratively disabled (one reassignment completed deployment in ~4–8 hours); clearing hung gpupdate/provisioning states with reboots; and applying pending post‑upgrade Windows updates which restored portal delivery on some devices. Persistent delivery failures were often resolved by remote automated re‑enrollment or reprovisioning; a minority required OS recovery, reimage, or device replacement when the Microsoft Store or Windows Update/service was faulty or the device had hung during initial OEM/refurbisher provisioning. Office/Outlook sign‑in failures caused by web‑installed Office were resolved after deploying Company Portal and installing Office through it. One investigation found a duplicate/externalized account that left Company Portal reported as installed but unresponsive and caused an Atlassian SSO loop; deactivating/removing the duplicate and restoring the correct account link restored portal functionality. On macOS endpoints an enrollment redirect to a different management provider was resolved by enrolling through the platform‑specific Self Service app rather than the Windows Company Portal. When portal access was temporarily degraded, browser‑based access to Microsoft 365 served as a workaround. Remote support tools were used during investigations when required.

Technicians resolved device OOBE/enrollment failures with coordinated fixes across imaging, inventory/Autopilot, identity, vendor/firmware, and network causes. Imaging and recovery: restoring a known-good OEM/corporate image or performing a controlled full reimage consistently recovered Windows laptops; Dell SupportAssist OS Recovery (F12 one-time boot) repeatedly restored corporate images and allowed successful Intune enrollment, Company Portal visibility, corporate naming, and managed-app deployment. Fresh Start behavior: local user-initiated Fresh Start runs were observed to remove devices from Intune and produce tamper‑protection/blob errors (65000); an Intune-initiated Fresh Start sometimes completed provisioning only when the device remained powered and reachable during OOBE. Inventory and Autopilot fixes: registering previously unregistered hardware, correcting suppressed Autopilot V1→V2 screens (suppression scripts), and reassigning correct Azure AD/Intune group memberships restored Autopilot/Intune registration. Identity and conditional‑access fixes: several incidents traced to Azure AD/conditional‑access/entitlement issues where resolving group membership or unblocking the account/device cleared 801c03ed and 0x80180014 errors, though partially provisioned devices frequently still required image recovery and re-enrollment. Server-side provisioning: one case documented an internal provisioning/enrollment service error that IT corrected; a subsequent retry completed OOBE and enrollment. MFA/authenticator behavior: technicians observed Microsoft Authenticator QR-scan or manual-code failures and situations where activating an alternate authenticator (Okta) changed the sign-in flow and prevented returning to the required Authenticator step, stalling enrollment; in at least one case enrollment proceeded after completing MFA on the user’s personal phone and then reconfiguring Authenticator on the corporate device. Vendor/firmware/driver actions: BIOS resets/updates, sfc/dism scans, targeted driver updates, and removal of problematic vendor tools resolved device-side conflicts — SupportAssist 3.6 was correlated with BSODs in multiple incidents. Network and OOBE connectivity: Wi‑Fi or OOBE network failures were a common cause of stalls; devices that remained powered and reachable sometimes completed Intune-initiated remediation and finished provisioning. Service-side incidents and mobile devices: Company Portal visibility problems were linked to upstream Microsoft service incidents and were resolved by a Microsoft-side patch in at least one case. Mobile/iOS enrollment repeatedly showed Remote Management/configuration‑download timeouts; affected iPhones were often diagnosed as defective and replaced under warranty or service‑provider processes when unenrollment/removal failed. When other remediation failed, technicians used full wipe/reimage or hardware replacement to restore a working corporate image and complete Intune enrollment.

Application availability and stalled installs were resolved by addressing publishing/packaging, entitlement/licensing, client sync/visibility, account provisioning, enrollment state, and device configuration. Support republished and repaired Win32 packages, consolidated or repackaged combined installers, adjusted supersedence/default deployments to replace legacy packages, and removed or blocked unstable installers that caused repeated hangs. Installers that prompted for local-admin credentials were added to the Company Portal or repackaged so the in‑portal Install ran without local-admin prompts. Missing catalog visibility or provisioning was fixed by correcting Azure AD group and entitlement membership, Intune primary‑user or Windows group assignments, Microsoft 365 license assignments, and by creating/provisioning required external vendor accounts before reassigning apps. Client-side visibility and stalled installs cleared after Company Portal synchronization/Work or School account re‑sync, signing users out/in, remote remediation of endpoint-protection blocks, or a full shutdown/restart/power‑cycle; multiple incidents required both a sync and a full reboot. Detection-script failures that returned 0x87d30065 were traced to scripts signed with certificates not present in clients’ Trusted Root/Trusted Publishers stores and were resolved by deploying the signing certificate to affected clients. Several cases were blocked by a manually installed copy of the same application; those required removal of the legacy/manual install (or administrative remediation) before Intune installations could proceed, and a few remote remediation attempts failed when Endpoint Privilege Management (EPM) activation hung. A small number of issues resolved only after backend Company Portal service fixes or overnight propagation following republishing. Separately, one case presented as a Company Portal launch failure where the Microsoft Store opened or the Company Portal showed an immediate error; that incident cleared after support troubleshooting and later user confirmation (steps were not documented). Operational examples included adding add‑ins to the Company Portal to avoid admin prompts, restoring Adobe Creative Cloud after entitlement/group fixes and reinstall via Company Portal, completing ChatGPT Team and Office installs after Company Portal sync plus reboot or remote endpoint remediation, resolving a Cloudya download after a backend portal fix, and publishing utilities and iOS apps through the Self Service Portal once device provisioning and app assignments were corrected.

Investigations confirmed the behaviour was caused by organisation-enforced settings rather than device faults. For Windows desktops a tenant-level "hard setting" in the M365 tenant enforced Walbrook/LIBF branding and caused any per-user desktop wallpaper or lock-screen changes to revert at next login. For macOS laptops a managed configuration profile had blocked iCloud Drive (the system displayed "a 'Profile' has set this setting"); support advised the user that the organisation used OneDrive for data synchronization instead of iCloud Drive. In both cases users were informed that personalisation or enabling the blocked feature was not possible under the current tenant/profile policy and no configuration changes were made.

Incidents that followed AVM FritzBox firmware changes presented as intermittent Wi‑Fi and wired network drops and, in some cases, Microsoft Teams authentication errors and Company Portal sign-in failures on Intune-managed Windows endpoints. The remediation applied to affected managed devices was deployment of two Intune/Company Portal packages that toggled the Windows NCSI active probe registry policy (HKLM\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\NoActiveProbe). The packages set NoActiveProbe to 1 to disable active probing and to 0 to re-enable it; the disable command used was: REG ADD HKLM\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator /t REG_DWORD /v NoActiveProbe /d 1 (and the inverse to revert). These packages were tested on affected devices and a limited rollout was recommended after verification. The incidents were observed after a FritzBox firmware update and affected both wireless and wired endpoints; the NCSI toggle was the effective workaround on managed systems in the investigated cases.

IT confirmed the corporate Windows 11 image had the Microsoft Store intentionally blocked and that consumer and some business applications were to be distributed via Microsoft Intune Company Portal. Resolution actions included adding affected apps to the Company Portal (examples: Google Chrome, Parallels for DATEV, Microsoft 365/Office, PDF reader, aText Premium, Canon Inkjet Smart Connect) and providing a whitelist entry for the Microsoft Store via the My Access service; after the whitelist was applied and the Company Portal became available, users were able to install required software and license-dependent apps resumed full functionality. In several cases the Company Portal did not appear immediately because Microsoft-side installation/service issues prevented its auto-installation; availability of the Company Portal restored the normal app delivery path. Some apps required elevated or device-level privileges (for example certain printer connector apps required admin rights to complete driver/connection steps), so those instances were handled with targeted administrative deployment or alternative packaging as appropriate. The Microsoft Store "is blocked" message matched the admin-managed Store policy, and separate device policies had blocked USB/mass-storage on at least one new Dell laptop. Sign-in failures or prompts when using personal Google/YouTube accounts on managed devices were treated as expected behavior under organization-managed accounts and were investigated on a case-by-case basis when required. An unrelated hardware fault on a Lenovo T14s Gen2 resulted in a device replacement.

The immediate change was undone and the deployment assignment was corrected. Administrators reverted the unintended image on affected devices, removed or adjusted the immediate assignment, and recreated a scheduled deployment with the intended start and end dates for the target device groups. The corrected scheduled deployment was then validated against the affected Windows 10, Windows 11 and macOS device groups to ensure the image only appeared during the specified window.

Support was unable to remove some devices from Apple Business Manager, so support-level Jamf removals and MDM unenrollments were performed as a workaround. Affected MacBooks were removed from Jamf and unenrolled from MDM; requesters were instructed to locally reinstall the devices and complete enrollment into the target ASM/Intune tenant for testing, after which the devices could be re-added to Jamf/ABM. For the iPhone case, administrators found the device’s remote-management/enrollment profile was not correctly assigned to the device serial; the profile assignment was corrected and the device was re-provisioned (factory reset/re-enrollment) which restored the expected remote enrollment flow and company/SelfService app behavior. When the eSIM QR previously used no longer worked, a replacement eSIM QR was issued. Overall, when ABM removal was not available from support, Jamf unenrollment plus local re-provisioning or correcting profile-to-serial assignments resolved the enrollment failures.

IT verified that the MDM configuration change prompting the dialog had been legitimately deployed by the organization's management. The user entered an administrator username and password to approve the change; IT confirmed the configuration applied successfully and closed the incident.

Support determined that permanent USB enablement could not be granted because the device was managed as Cloud Only. The user was instructed to upload required files to OneDrive and access them by signing into OneDrive with their Microsoft (work) account as the supported alternative. The ticket was closed after the user adopted the OneDrive workflow.

Support verified that the device name had not been reused, located the device record in Intune by searching the serial number, and issued a remote lock/block from the Intune portal. The device was successfully locked and marked in inventory.

Investigation determined that the extension could not be centrally published through the public Chrome Web Store and that two enterprise options existed: use the IU Chrome Enterprise Private Store (which required an IU Google account, developer console access, and a paid developer subscription) or deploy the extension through Intune by assigning a profile/policy to target devices. The security team required a manual penetration test/assessment before corporate distribution, and the distribution scope remained to be clarified before proceeding.

Applications were installed through the Microsoft Intune Company Portal rather than by elevating the local user account. In one case support/IT assigned the Cloudya application to the user in Intune so it appeared in the Company Portal; the user then opened the Company Portal app (launched from the Start/Windows Search), located the app, and installed it. Installation from the Company Portal completed without requiring local administrator credentials and avoided the UAC administrator credential prompts that occurred when running downloaded installers. Support also explained that IU-managed devices were provisioned without local admin rights by default and that application delivery and device controls were managed centrally via Intune/Company Portal rather than by granting end users administrator access.

A separate Intune device configuration policy named "U-Bildschirm-Timeout konfigurieren - Test" was created and the screen timeout value was changed from 15 to 17 minutes. The target user/device was explicitly added to the Azure AD/Intune assignment group (IU-DE-AAD-ASS-INTUNE-IT-PolicyGroup-W10-U-EnergySettings_Devices) so the new policy applied to that device. After assigning the device to the test group and allowing Intune policy propagation time, the configured screen timeout took effect; a simple restart prior to assignment had not enforced the change.

Support confirmed the Company Portal was not supported or provisioned via the IT Service Portal and closed the tickets after advising requesters to submit dedicated access requests in the IU Meldeportal (Jira Service Management) so the responsible team could grant Company Portal rights. In one case an approver assignment was adjusted as part of the handover to the owning team.

Investigated the sync behavior and reviewed provided screenshots and examples; determined that Inventory360's import process used the device's "last logged-in user" attribute rather than Intune's "primary user" field, which explained the observed assignment discrepancies (notably for devices where admin/shared accounts were used). The finding was communicated to the requester as the root cause of the mismatched assignments.