Cases were resolved by reconciling vendor inventories and user assignments, restoring or reallocating seat capacity, completing renewals or one‑off purchases when vendor minimums blocked access, and correcting admin‑console entitlements so intended products appeared in enterprise portals. Desktop client errors such as “access expired” or download‑token failures cleared after vendors reissued download links/tokens or after targeted reinstalls, repairs, or redeployments that removed legacy or conflicting components. SSO and sign‑in loops were traced to duplicate, migrated, or unlinked identities and were cleared after restoring or re‑linking vendor organization connections, consolidating Azure AD/Okta memberships, removing legacy personal vendor bindings, restoring the correct primary email on vendor accounts, or restoring managed‑app registration and completing SSO reauthentication. Approval‑workflow and provisioning‑group failures were restored by recovering Azure AD/group memberships, recreating provisioning groups from logs/backups, adjusting approval routing or recording manual approvals, and reconciling vendor assignments. Vendor‑side remediations included reissuing invites/redeem links, replacing single‑activation keys that had exhausted counts, clearing payment‑hold states after invoices posted, and escalating tenant‑ or mass‑scale incidents to vendor support when local changes did not clear detection or propagation bugs. Cases involving consumable credits or assets bound to personal or deactivated vendor accounts (for example, Adobe Stock credits) required reactivating or reconciling the affected vendor account and coordinating with vendor support to determine transferability; outcomes varied and some credits remained tied to personal accounts until vendor migration. Some incidents were resolved simply by directing users to the product‑specific URL (deep link) which bypassed misleading portal pages or purchase prompts and allowed access to the licensed service. Other incidents involved new vendor features that were gated and required an administrator to enable them (for example, Adobe Firefly Video‑AI); those tickets recorded vendor notifications of license inconsistencies and pending suspension and were handled via vendor communications and admin enablement rather than local configuration changes. When no seat existed in vendor inventory or a product had been intentionally discontinued, users were routed through the software request/license provisioning or procurement process and some requests were declined with alternative software recommended. Representative resolved cases included an Acrobat Pro seat bound to an obsolete institutional email fixed after vendor reassignment and reinstall, a Creative Cloud seat that required manual transfer after an automated conversion, Adobe Portfolio sites created under personal Adobe IDs that required manual vendor migration, and Rhino serial/version conflicts (Rhino 8 vs 7) resolved by applying the institutional serial, removing conflicting private/trial installs, and redeploying the enterprise package.

License and edit-access incidents were resolved by reconciling license inventories, mapping identities to vendor accounts, and ensuring team/workspace capacity and approver mappings matched intended entitlements. Technicians reassigned correct paid/full seats when users had free-restricted or wrong-product licenses; Okta- or Azure AD-assigned license changes typically propagated within approximately 5–10 minutes in observed cases. Where approval workflows pointed to the wrong approver, approver mappings in Automation for Jira or the service catalog were corrected and approvals were re-submitted. Free-restricted edit limitations were addressed by upgrading teams, moving content into paid workspaces, or granting temporary paid seats with recorded cost-center approval and scheduled revocation. When creation was restricted to a particular team, remediation included correcting SCIM/group-to-team mappings or group membership, adjusting team-admin controls, or relocating content into a paid workspace where the user had creation rights. Duplicate vendor accounts and stale SSO/vendor sessions were consolidated or cleared; affected users reauthenticated and browser caches were cleared as needed. Provisioning failures were handled by removing and recreating Okta/Azure AD provisioning entries, creating missing AD/Okta group mappings required by the vendor, reapplying license assignments, and removing conflicting groups or pending vendor-side assignments. Tenant-capacity limits were resolved by freeing or purchasing seats; several cases required escalation to the Applications/ARM team for additional licenses. Third-party integration failures were resolved by enabling or purchasing required tenant/app licenses and enabling integrations at the correct tenant or security-group scope; some situations required vendor-side enablement or escalation. For vendor-hosted boards outside the institution’s tenant, affected users were routed to the owning internal team or instructed to request access via the service portal. Interim collaboration was occasionally enabled without purchasing seats by sharing public board links or temporarily adding collaborators into a paid workspace. Trello Standard requests were handled by provisioning paid Trello seats, transferring board admin, or migrating boards when AD/Okta provisioning mappings were absent.

Access and feature failures were resolved after product entitlements, Marketplace/app billing seats, identity attributes, site alignment, directory/group membership, and space/project permissions were reconciled with each product’s licensing model. Reinstating or assigning Jira Software, Jira Service Management, Confluence, or Trello entitlements restored board, backlog, page, and premium trial access in numerous cases; affected users sometimes had to re‑authenticate via organization SSO before all features returned. Marketplace issues were resolved after clarifying and aligning billing scope: several Confluence add‑ons were found to be licensed by site tier (site/user tier) rather than by individual users, which produced unexpectedly high recurring costs (example: a purported “free for 10 users” add‑on requiring site‑tier billing of several thousand USD/year before discounts). Academic discounts were applied in some cases and procurement/justification approvals were required before purchases proceeded. Jira Service Management allowed public portal submissions without individual Jira seats but required JSM agent seats to restore agent/queue views, assignments, status changes, and public comment capabilities. External collaborators required external‑IU addresses, appropriate product entitlements, and explicit space permissions to regain Confluence access. Marketplace/trial banners and app feature loss cleared after aligning app billing (site/instance vs per‑user) with actual usage or after converting trials to paid seats; where procurement was not completed, teams were given alternatives or the ticket was closed when no license was provisioned. Short‑term mitigations used while approvals completed included temporary reassignment of existing paid seats to critical users, exporting data via the Jira REST API, or recommending alternate tools. Directory/group permission changes typically propagated in 5–10 minutes but could take ~40 minutes or, in some group‑sync windows, up to 24 hours; automated approval requests were observed to auto‑decline after 14 days. Some restricted areas remained governed by space/project owners and required those owners’ explicit permissions even after license assignment.

Support determined Copilot access and related feature availability were governed by three primary checks: completion of the IU Learning Hub "Copilot for M365 Essentials" learning path, acceptance of applicable Microsoft preview/preview terms, and membership of configured license‑assignment security groups (Entra/Azure AD or Okta). Course completion typically changed the course status to "completed" and triggered automatic Copilot SKU assignment without a separate user notification. Support recorded recurring automation and backend failure modes—"Could not connect to MS Graph Api," "Could not add User to Group," Automation for Jira missing ticket payloads, and Microsoft Graph Request_BadRequest duplicate‑membership responses—and confirmed Graph duplicate errors indicated redundant add attempts rather than successful assignment progress. When Atlassian display names or UPNs differed from Entra/AAD SCIM exports (for example marvin-ole.de-frenne@iu.org vs marvin.de-frenne@iu.org) support verified Entra/AAD and SCIM records and confirmed whether a license already existed. Where automations were backlogged, stalled, or errored, recoveries included reinitializing connectors, repairing Automation for Jira authentication, copying and rerunning backlogged automations, re‑adding users to the appropriate license‑assignment groups, or manually assigning the Copilot SKU or group; manual group or license assignment restored in‑app Copilot and premium functionality within minutes while backend propagation completed. Timing and propagation behavior were consistent: scheduled group sync windows (~4‑hour intervals) and backend propagation typically produced Copilot features within 24–72 hours after assignment or training completion, with occasional delays up to 7 days. Teams Copilot showed a blue/violet icon with an in‑app "keine Lizenz vorhanden" message when a Copilot license was missing; reassigning the license or adding the user to the correct license group restored the normal icon and functionality after client reload and propagation. Teams Premium meeting summary failures reporting "Transcript and recording must be turned on" were resolved after transcription/recording were enabled and license availability was ensured. Support tracked licensing quotas and eligibility: exhausted quotas were handled by procuring additional seats via reseller/cost center, and some external or out‑of‑scope accounts were ineligible and requests were auto‑declined. Missing companion app capabilities (for example Agents management, Microsoft Designer features, Clipchamp media features) were attributable to tenant product licensing and SKU differences; in those cases support explained licensing and did not change tenant entitlements when no additional SKU was approved. For access requests, support instructed requesters to use the dedicated "Copilot for M365" request form on the IT Service Portal (Jira Service Management); ad‑hoc requests submitted outside that process were redirected or closed and resubmitted via the portal. When automation failed to create requests, support created the application/license request in Jira and proceeded with the manual remediation steps above. Common automation error messages, the diagnosis steps taken (for example verifying Entra/AAD and SCIM records when Atlassian showed different UPNs), and the manual assignment/workaround steps were preserved as repeatable remediation paths.

Cloud-stored projects that appeared missing after workstation migration were recovered by moving MAXQDA project files into a local folder; after the files were local MAXQDA opened them and displayed the expected cloud-save warning. Installers, trial installs, and product updates that required local-administrator privileges completed after an administrator performed the install or users were granted temporary elevated install rights through existing management workflows (for example Company Portal/Intune or macOS Self Service); remote-assisted installs that stalled due to absent on-client authentication finished once VPN/remote-authentication was restored, an administrative install path was used, or temporary local administrator access (for example via LAPS or a local admin session) was provided and the application was installed under that account. License entry, activation, or license-file loading issues were resolved by unblocking or reassigning licenses in the inventory/asset system, adding users to the appropriate management groups, or supplying the MAXQDA serial/license key or license file to the user for on-device entry. Where activation failed because the installed build did not match the license, support generated and supplied matching, version-specific license keys and coordinated installation of the corresponding MAXQDA build; documented cases succeeded after installing the matching build. One incident of a license-file-based failure reported as 'The license file cannot be loaded. Error 2x0' was caused by an expired license file; acquiring and installing the renewed license file restored application functionality. For macOS MDM-blocking errors, making the app available in Company Portal or granting temporary administrative access allowed installation in many cases; where Company Portal installs remained blocked an administrative session was used to manually download and install MAXQDA from the vendor website. Requests for audiotranscription (f4) licenses were routed through departmental procurement when an additional license or publishing purchase was required.

Support validated that premium features required a per-user (Premium) entitlement on the account that owned or invoked the resource. For Power Automate, premium connectors (Salesforce, Jira), HTTP/REST actions, Desktop recorder usage, and Dataverse table editing required a Power Automate per-user (Premium) license on the flow owner or invoking account. Cases were resolved by applying the per-user (Premium) license to the owner, adding the owner to an Azure AD provisioning group that granted the entitlement (example: IUG-AAD-ASS-License-IT-PowerAppsPerUserForFaculty), or reassigning ownership to a licensed service account. Development teams started Power Automate Premium trial licenses on dev/service accounts when building premium-capability flows and then migrated flows and ownership to licensed service accounts for production; support recorded license-group names and service-account assignments in ticket metadata to aid tracking. Where a per-user license had already been applied but flows remained disabled, support verified the exact license SKU to rule out Power BI or Microsoft A5 confusion and observed that license assignment sometimes required time to propagate across services. Azure AD group-assigned licenses were noted to have limitations: group assignment commonly did not enable standalone Power Automate flow ownership and often enabled premium connectors only when flows were invoked from Power Apps. For Power Apps, support found that apps containing Premium components failed to open for Azure AD guest/external users unless the guest user had a Power Apps Premium license provisioned in the host tenant; assigning the Premium license to the guest in the host tenant allowed the guest to start the app and see Premium content even when the guest's home tenant had no license. In one endpoint case the Power Automate app was missing on Windows 10 because the app had been targeted only to Windows 11; adjusting Company Portal targeting or provisioning the app to Windows 10 devices restored installation and resolved desktop-install symptoms.

Incidents were resolved by restoring a valid licensing path or by supplying standalone activation for isolated workloads. For KMS-related failures, technicians restored network routes to corporate KMS hosts (bringing devices on-site, arranging VPN routing that traversed to the KMS, or changing VM networking such as using bridged networking or running VPN inside the VM), repointed clients to KMS hosts with slmgr.vbs (SKMS), installed IPKs where appropriate, forced activation with /ato, and inspected licensing channels with slmgr.vbs /dlv to confirm VOLUME_KMS versus other channels. KMS host repairs and migrations included deploying or repairing KMS hosts, verifying DNS SRV/A publishing and TCP/UDP 1688 reachability, then repointing clients after fixes. Air-gapped or isolated analysis workloads and VMs were returned to licensed state by supplying Windows ISOs and MAK/retail keys to run without KMS; Office/offline secondary-device requests were handled similarly when institutional entitlements permitted non–Microsoft 365 keys or ISOs. Parallels Desktop guests on macOS were remedied either by providing a direct corporate route for the VM or by standalone activation. One Microsoft-update–related sign-in block was cleared by pausing the update and supplying a product key; desktop personalization (black backgrounds) cleared after activation and resetting Background in Settings > Personalization > Background. For externally hosted vendor license servers, technicians contacted providers to update allowlists or add required public IPs (for example adding 3.127.125.178 to a vendor allowlist), confirmed the provider-side change, and then verified license access. When Volume Licensing or Microsoft 365 Admin Center entitlements were missing or overwritten (for example reseller/contract changes that removed Windows 10/11 licenses), technicians verified the agreements and product-key visibility, engaged Microsoft Volume Licensing Support and the reseller to restore entitlements or obtain keys/downloads, and used temporary workarounds such as booting affected laptops from USB/thumbdrive for image provisioning until portal access was restored. Users often lacked rights to change product keys, so technician intervention was frequently required. Surplus or decommissioned-device license requests continued to be handled through asset-surplus or procurement channels rather than licensing workflows.

Support investigated multiple Power BI, AI Insights and Fabric licensing/capacity incidents and recorded actions and outcomes. They audited Azure AD license state and removed conflicting SKUs (for example A1/A1+), then assigned or re‑assigned Power BI‑capable SKUs (examples included Microsoft 365 A5, Power BI Pro or group‑based Power BI Pro); access was restored after license propagation (delays ranged from minutes up to 24 hours). Where authoring limits or large‑dataset (>2 GB) failures occurred, support assigned Power BI Premium Per User (PPU) add‑ons which restored authoring and large‑dataset capabilities; content protected by PPU still required viewers to hold equivalent PPU or for tenant‑level Premium to be provisioned. A paginated‑report failure executed via Power Automate was resolved after the tenant applied a PPU package. When Power BI AI Insights returned DataSource.Error containing PowerBINotAuthorizedException, support checked Azure AD license state and the tenant's Microsoft AI credits/entitlement; restoring a Power BI‑capable SKU and ensuring available AI credits (or enabling a time‑limited Fabric/AI trial where appropriate) cleared the error and restored AI analysis. External and guest failures were triaged by ruling out conflicting signed‑in accounts (tested in a private/Incognito browser) and by provisioning Power BI‑capable licenses via Azure AD user or group assignments; after group‑license propagation guests could open apps and view dashboards. Support processed approval requests and assigned Pro or PPU seats — including time‑limited assignments for external consultants when requested — and reactivated or corrected accounts and group assignments when those prevented Power BI visibility in the user portal. When tenant license inventory was exhausted, support procured additional PPU or Pro seats through the normal vendor flow (purchases processed through Bechtle) and activated them in the tenant; new assignments restored access. To reduce reliance on individual personal seats, support used Azure AD group‑based licensing and added service accounts to Premium‑licensed groups so content ownership did not depend on individual users. Separately, Microsoft Fabric Workflow Management required tenant Fabric Premium capacity (F‑SKU, e.g., F2) or an active Fabric trial; assigning only a Power BI Premium license did not enable Workflow Management, and Fabric capacity provisioning and ownership were handled outside CloudOps (referred to Data Platform). Support also observed that approval workflows (for example Application Request / Automation for Jira) could block license assignment; updating the approver or completing the approval and then assigning the license resolved pending‑assignment delays.

Access interruptions were resolved by reprovisioning, reassigning, reclaiming or converting entitlements across vendor admin consoles, identity providers and procurement/billing systems. Group‑scoped misassignments were fixed by correcting Azure AD/Entra or Okta group membership and removing incorrect nested groups; device and Intune/Company Portal entitlements were aligned either by adjusting group membership or by applying per‑device entitlements when required. Stale or consumed seats were recovered by cleaning inactive accounts, reconciling limited vendor pools, and ordering or provisioning additional licenses so seats could be assigned. Third‑party desktop and vendor product issues were resolved by obtaining or converting appropriate version entitlements (for example separate licenses required for major upgrades such as Citavi 6→7), coordinating with vendors to migrate or reissue license keys, reinstalling packages via Company Portal where applicable, and entering replacement keys during short remote sessions; replacements and key changes were recorded in a central inventory for traceability. Where vendor products presented activation or login/password prompts after configuration files were applied (for example an Affinity2.defaults case on macOS), investigators confirmed whether institutional licensing was issued only via formal approval workflows and routed requests accordingly; license transfers were not performed without an authorized request/approval. SaaS trial expiries and subscription conversions (for example Perplexity Pro institutional trials) were escalated to product‑specialist or licensing owners when API keys or continued Pro access required additional approval. Billing or activation blocks were cleared by coordinating with vendors, approvers and accounting and using admin/stored accounts to update payment details and reactivate subscriptions; expired invitations, activation links or vendor verification emails were reissued and verified to restore trials or premium access. Microsoft 365 desktop activation failures were resolved by resetting or reapplying SKUs and having users sign out/in; accounts intentionally placed on cloud‑only SKUs were documented and users were informed of web‑only access. Administrative and policy cases (for example post‑graduation A5→A1 conversions and 180‑day cutoffs versus legacy curriculum exceptions) were recorded and routed to licensing owners, procurement, or the licensing intake for manual extensions or exceptions; routine ongoing renewals (for example Adobe Acrobat Pro) were handled via documented license‑confirmation/renewal forms and routed to procurement when completed. Minimal CMDB and vendor records (group names/IDs, approver details, payment/invoice references when available, inventory entries, key‑user contacts) were kept for traceability and future reconciliation. Typical propagation windows observed were ~5–10 minutes Okta→Azure, ~20–60 minutes for many Microsoft 365 license changes, up to ~1 hour for Dataverse/PowerApps and up to ~24 hours for some Company Portal/Power BI or vendor package availability.

Procurement and entitlement blockers were recorded in ticketed records that captured license model (per‑seat, concurrent, course, student‑lab, single‑computer, site), counts or quotas (including metric‑based quotas such as Lines‑Of‑Code), pricing, subscription vs. perpetual status, cost centers/project codes, approvers, vendor quotes, and proration windows. Vendor entitlements and model details (concurrent vs. per‑seat, transferability, duration, consumable credits, floating/network options) were confirmed with vendors and logged. Marketplace and vendor payment quirks (credit‑card‑only storefronts, purchase limits, ambiguous per‑instance billing, app‑store or education‑portal flows) were recorded as procurement blockers and purchases were held until billing metadata, approver identity, and invoice conversions were clarified. Consumable/metric‑based quotas (LOC, build minutes, API calls) were treated as consumables; increases were processed only after approvals and invoice handling. Where vendors issued individual license codes via external storefronts, keys and distribution/billing details were logged with the purchase record; payment‑path failures, refunds, and transfers from personal to institutional accounts were processed where supported. Orphaned ownership and reseller‑change issues were escalated to procurement or vendor support and alternate authorized sellers or enterprise/volume purchase paths were used when necessary. Administrative or enterprise seats were requested or created when missing admin accounts or lack of local admin rights blocked provisioning; invitation and account‑creation failures were resolved by correcting invitation metadata, reconciling HR/leaver lists and orphaned accounts, re‑sending corrected invitations, and consolidating duplicate tickets. Product architecture and authentication compatibility (local license managers vs. cloud/SSO models and the need for on‑premises or hosted license servers for remote/VPN machines) were recorded and escalated when vendor onboarding data or customer numbers were missing; where central teams declined to host license servers, implementation guidance and recommended next steps were documented. Renewals, prorations, and time‑sensitive short‑term licenses were tracked against academic deadlines and offers were held until procurement windows and approvals were secured. When titles were excluded by institutional policy or formal decisions, exclusions were recorded and supported alternatives or funding/workaround paths were offered and documented. Example outcomes from resolved cases included: an institutional decision recorded that paid SPSS licenses would not be procured (a rectoral decision), alternatives were proposed and documented (SPSS Demo, R, PSPP, SAS OnDemand for Academics; SAS requests routed via the library), trial/install attempts failed when users lacked local admin rights and those failures were logged, and funding or individual purchase requests were routed through IU‑Kompass when requested. In another case, Archicad license ownership and handling were assigned to departmental colleagues and licensing policy was clarified: Archicad access was permitted for teaching staff and enrolled students only when usage was not mandatory or exam‑relevant, was at the user’s own risk, and IU would not cover extra costs; this policy and ownership assignment were recorded in the procurement record. Practical provisioning actions observed in resolved cases included assigning users to existing Azure AD groups to make software available in the Company Portal while procurement completed, purchasing and deploying additional licenses/credits, renewing and increasing license counts or quotas (including LOC quota increases after invoice processing), creating or designating departmental/library accounts, moving billing off private accounts and issuing refunds where supported, and documenting payment/governance blockers or explicit “won’t do” decisions. Supplier negotiations, subscription upgrades, applied discounts, purchase approvals, and conversion of order confirmations into formal invoices for finance systems were documented; time‑sensitive digital signing/e‑signature workflows were completed when required. Recorded outcomes included successful post‑approval provisioning and quota increases, vendor‑issued license keys and billing cadence decisions, converted invoices for institutional approval, explicit records where license transfers were not permitted and additional seats or quota purchases were made, and collaborative research scenarios closed as “wont‑do” when partners hosted licenses and no institutional procurement action was required.

Capacity, feature, licensing, and provisioning problems were resolved by ensuring events were hosted under the institutional account/subdomain that actually owned the Zoom Meeting, Webinar, Events, or large‑meeting add‑on. Where ownership mismatches or orphaned accounts caused missing features, support reassigned ownership when permitted or coordinated with the licence owner to host events and add alternative hosts or designated schedulers when capacity was tied to a single named account. Licensed Zoom features became available after the named institutional account held the appropriate Zoom product and affected users re‑authenticated the Zoom client or accepted the emailed licence invitation; support routinely checked Outlook Junk when invitations did not appear. When Zoom revoked licences en masse or a Zoom‑side error caused meetings to terminate at ~40 minutes, support restored licences and performed bulk reassignments using existing user lists to recover affected accounts. Large‑meeting and webinar capacities (examples: 300, 500, 1000, 1600, 3000) were availability‑checked before assignment, applied temporarily for specific events and tracked with Jira Automation due dates, and removed after events when appropriate. Licence transfers were sometimes refused because transfers would remove associated data/reports; in those cases events ran from the existing owning account and the licence owner coordinated hosting and alternative‑host arrangements. Orphaned enterprise accounts still owned by departed employees were recovered by transferring ownership or creating/reassigning an institutional account so teams could access scheduled livestreams and licences. Truly multi‑owner Zoom accounts required an organizational/shared mailbox as the account owner and involved mailbox provisioning/sync when attaching the mailbox; Zoom licences could not be assigned to generic shared/group user accounts. Requests to run non‑Zoom products from shared/team mailboxes or service accounts were triaged as vendor‑specific; support recorded licence cost information, validated vendor ownership rules, and engaged procurement or the vendor when needed. For routine provisioning, support requested cost‑centre and manager approval evidence and assigned Zoom Pro/Licensed accounts to named user accounts; Automation for Jira was observed to automatically decline and close provisioning requests after 14 days without manager approval, requiring resubmission with approvals. Licensing inventory, available Education licence pools (~2,000 units), and procurement steps were documented and procurement was engaged when capacity beyond available pools or additional event tiers were required; as an example, support informed requesters that a 1,000‑seat webinar licence cost over €1,000 per year and requested completed procurement forms and a target cost centre before purchase. Microsoft Teams was used as an alternative for very large public or international‑facing events; support prepared dedicated Microsoft service accounts and confirmed account limits — examples included dedicated service accounts supporting up to 300 or 1,000 active participants and Microsoft webinar/live‑event capability supporting up to 1,000 active participants and up to 10,000 view‑only attendees. Informational inquiries about licence validity were escalated to the specialist team; specialists provided effective and expiry dates for named accounts and those dates were communicated to requesters.

Support routed vendor-specific pricing, licensing and eligibility queries to product owners, procurement and specialist teams and collected concrete per-license billing models, terms and expected-user/site counts so budgets and approval workflows could calculate per-month and per-year totals. Support assembled consolidated cost overviews for board and regional requests covering SaaS, desktop and hardware vendors (examples: Salesforce, Twilio, Microsoft Azure AD/A1/A5/PowerApps/Dataverse, Workday, Okta, LinkedIn Learning, Adobe, Canva, Calendly, JetBrains) and recorded confirmed figures and outstanding items requiring vendor/procurement confirmation. Captured vendor figures included Adobe Sign transaction billing at €2.34 per transaction, Acrobat Pro/Acrobat Pro DC figures recorded in previous reviews (example: €20.66 per employee per year) and an example procurement instance where no spare seats were available and support purchased/upgraded an Acrobat Pro licence via a corporate credit card at approximately £200 per year once payment capability was provided. Support recorded Adobe All Apps Pro for Higher Education at €30.66 per student per year, Canva Pro at €12.60/month per user, Calendly at €124.80 per user per year and an approximate JetBrains All Products/Toolbox cost (~€800/year). Adobe Sign branding templates were created and assigned within an existing Adobe Sign account and only transaction charges applied; Acrobat deployments required procurement approval and license assignment via the IT Service Portal / Jira Service Management. For licensing models that depended on transaction volumes or site counts, support requested expected-usage counts and cost-center information so spend could be allocated. For non‑SaaS licensing (font embedding/licensing) support recorded vendor registration-fee schedules (example: Code2000 fees), attempted vendor payment flows (PayPal) and documented where vendor flows required personal accounts or exposed only single-user amounts; unresponsive vendors blocked formal procurement and risked duplicate purchases. Support escalated specialist licensing queries (example: Microsoft Dataverse) when required and documented prolonged specialist-team delays when they occurred. Support respected explicit user requests to withhold license assignment when pricing information was provided; one user cancelled an Adobe Pro request for redaction due to cost and used an alternative workflow. Support also noted short-term feature workarounds (for example vendor-hosted online PDF merge tools when Acrobat Reader lacked merge) and documented service outages when they affected those alternatives.

Blocked provisioning, purchases and renewals were resolved by restoring or supplying missing billing, approval and legal/privacy metadata, correcting approver mappings and notification routes, and clarifying licensing eligibility for external accounts. Support manually reassigned approvers and corrected misrouted requests when request type or service‑desk routing directed approvals to the wrong approver; requests that Automation for Jira had auto‑declined or auto‑closed after the 14‑day timeout were recreated or resubmitted under the correct cost centre when reopening was not possible. Procurement created vendor/supplier records in the ERP when PO/API calls failed so suppliers and payment methods were recognised; expired or invalid quotes/offers were replaced and central customer contacts on orders were verified to address API/PO errors such as 'Supplier is not in the list.' Billing was restored by reallocating charges, creating numeric cost‑centre entries, switching payment methods to organisational cards or billing owners, and moving seats under central billing owners; licence activations and subscription upgrades proceeded after approvers completed approvals, and seat shortages were handled by seat reallocation or purchasing additional seats. For per‑user or unique‑email licensing, procurement confirmed canonical user email lists, quantities and billing cadence and evaluated central purchase versus per‑user options. Procurement paused acquisition of tools that process personal data or use AI until DPA/MSA, data‑flow diagrams and privacy/security reviews were provided; common DPA issues (for example incorrect company address fields and incomplete data category listings) were corrected and sent to Legal for review. Vendor reporting limitations were mitigated by merging vendor user/license exports with HR/identity cost‑centre exports to produce per‑cost‑centre lists, and product credentials or secrets were supplied via the central password manager when required. When specialist approvals caused prolonged delays, teams obtained licences via ad‑hoc/manual purchase or manual provisioning to unblock essential work, and in some cases users procured access privately when approvals could not be obtained promptly. When applications were added to the Self‑Service request portal, they were bound into Self‑Service and configured following existing templates and approver routes were validated as part of onboarding. Example outcomes included switching accounts to organisation payment methods to enable central billing, licence provisioning after cost‑centre correction, restoration of SSO access after approver mapping fixes, procurement progressing after DPA/MSA corrections and Legal review, and urgent requests being reissued or manually procured under the correct cost centre when original tickets had been auto‑closed or misrouted.

Responsibility for campus and external SaaS licences varied by product and procurement terms. The Library managed the Unipark survey tool and student‑related access; the Examination Office (Prüfungsamt) managed Turnitin. Mentimeter licences were available at IU, had been provisioned via the Self‑Service licence portal and published in Okta for SSO, and a campus contact for Mentimeter was recorded; support followed up with requesters via Microsoft Teams when clarification was needed. Paid Kahoot requests had previously been declined while Mentimeter Enterprise was offered as the centrally licensed alternative; tickets have documented observed participant limits for lightweight tools (Kahoot ~10 participants, Polly (Teams app) ~25 participants) and no campus upgrade path for Polly was recorded. For Autodesk Education, support recorded that the vendor required an institutional verification document and that confirmations could be issued by the program director, the disciplinary supervisor, or Scientific Coordination; requesters were directed to obtain that verification from those campus roles. The campus MathWorks licence (MATLAB/Simulink, “Simunik”) was available to enrolled students and lecturers without per‑seat limits and access was provisioned via the university/IU portal. NI LabVIEW had no campus deployment licence and requesters were directed to coordinate local procurement with departmental owners. Many productivity and whiteboarding apps had no central campus licence, so licence assignment, procurement and cost‑centre billing were routed to the owning department or procurement contact. Support recorded product ownership, routed licence‑approval and billing actions to the appropriate owner, and—when approval workflows stalled in Automation‑for‑Jira/Application Request because approvers were unavailable—support or licence administrators sometimes completed provisioning by assigning licences directly to requesters to clear pending approvals. Representative outcomes recorded in tickets included redirecting Screencast‑O‑Matic requests to MyCampus course links, declining paid Kahoot requests while offering Mentimeter Enterprise, closing SurveyMonkey requests after approver confirmation and redirecting requesters to Unipark/MyCampus, marking Stata inquiries as “Won’t Do” when the software was already listed, and reviewing free qualitative alternatives (AQUAD8) before recommending manager‑approved MAXQDA and coordinating installation for staff. For statistical software policy, SPSS had been removed from teaching procurement per a rectoral decision (Nov 2021) and was treated as blacklisted for teaching use; PSPP was recorded as a free SPSS‑compatible alternative available via the Company Portal on Windows endpoints. SAS was provided via the Library’s Team Library and an SPSS demo existed; R was recommended as a no‑cost alternative. Support recorded a named campus contact for full IBM SPSS research licences (ellen.rohde-buhr@iu.org). MA Support provided installations and support for staff only; students were handled by Studysupport/Techsupport and were instructed to contact techsupport@iu.org to enquire about student licences or access. Tickets with no requester response were auto‑closed after 14 days of inactivity.

Access and paid features were restored by aligning user sessions/accounts and confirming org‑level entitlements, and by correcting identity and license assignments. Support actions that resolved incidents included: - Confirmed cases where GPT‑4 was accessible in the OpenAI Playground or API but ChatGPT Plus features were absent in chat.openai.com because the institution’s standard package did not include ChatGPT Plus; admins communicated package limits and provisioned per‑user Plus/Pro or Team seats where available. - Signed affected users out of personal OpenAI accounts, removed incorrect Microsoft/Okta auto‑bindings, repaired SSO links, and provided direct institutional sign‑in links to avoid browser account conflicts. - Recovered institution‑linked OpenAI accounts via the service’s password reset flow when credentials were lost. - Reissued Team invitations or reallocated seats after manager approvals (some approval emails were accepted post‑timeout and admins then sent paid invites) rather than reopening auto‑closed approval requests. - Confirmed org‑level model entitlements (some corporate orgs exposed only GPT‑3.5), provisioned Plus/Pro seats individually (OpenAI lacked bulk tooling for Plus/Pro), and moved heavy users onto institution‑paid Team seats or routed charges through departmental invoicing or reimbursement. - When portal form selection prevented provisioning, users were routed to the correct software/license request form so workspace invitations could be issued. - Recreated or redeployed custom GPTs and artifacts that had been built under personal accounts after those accounts were moved into the Team workspace. - Used alternatives for feature or quota gaps: Azure‑hosted DALL·E 3, the institutional KI Portal, Microsoft Copilot for Teams/Office, or the OpenAI Playground as interim workarounds. - Updated stale internal documentation (for example outdated SharePoint contacts) encountered during remediation. The fixes were primarily administrative (session/account alignment, invitation and seat correction, SSO repair, and entitlement verification) and were logged where bulk provisioning was unavailable.

The CORPCDT template and its recipient-selection process were updated to include users whose Business name was set to "Nationwide" and who had current CeMAP registrations. The scheduled recipient-population job was confirmed to run on a weekly cadence; because 1 Nov 2024 fell on a Friday, the next job run occurred on Monday 4 Nov 2024 and picked up registrations from the prior window, after which the CORPCDT emails were sent to the Nationwide cohort.

Technician cleared the stuck client state so the ConfigMgr deployment could proceed. The resolution steps included a Group Policy refresh and restarting the Configuration Manager (ccmexec/SMS Agent Host) client processes to remove the pending-change state in Software Center. After the client services were restarted and the pending state cleared, the Software Center resumed the application deployment and Citavi installed successfully.

Support confirmed Adobe Digital Editions (ADE) had been installed via the Company Portal/Software Center and that the application itself was functioning. Support explained that publisher DRM‑protected eBooks (for example, Pearson and Onleihe titles) required per‑user authorization with a personal Adobe ID; the corporate portal installation did not provide or manage those per‑user Adobe DRM authorizations. An inventory/licensing check found ADE and Calibre to be license‑free. Functional testing showed that Calibre could not open or reliably edit/display covers for Adobe‑DRM‑protected eBooks, whereas ADE was required to open those protected files. In one reported case ADE was presenting a 'new license required' error and only allowed individual chapter downloads; providing ADE version 4.5.12 via the Company Portal and installing that version resolved the download/license error and restored full‑book downloads.

Cases were routed to internal stakeholders and vendor contacts and relevant contract excerpts, vendor guidance, and stakeholder notes were located and shared with requesters for legal or marketing reference. Microsoft: staff confirmed that stock/archival photos, clipart, and icons bundled with Microsoft Office were permitted for use in presentations and could be included in recorded and published training videos; requests to use Microsoft’s broader stock image offering programmatically (for image‑search/serving pipelines), to download and persist images in a team datastore, or to obtain API/programmable access were escalated to Microsoft support and internal account teams. In one such case an informal verbal approval was received but no written permission existed, so staff opened formal escalations and recorded vendor/hand‑off delays and outstanding guidance. Adobe: staff located the Adobe Creative Cloud/Adobe Stock clause (Agreement Number 00870185), preserved the original German text and English translation, and documented that faculty and staff could access Adobe Stock on‑demand services and may license, use, reproduce, and archive images as described in that contract; because the contract did not explicitly permit license transfer or third‑party redistribution/resale, transferability questions were flagged for additional legal/vendor review and guidance was sought and recorded. Third‑party software (example: Anaconda) and screen‑recording questions prompted legal review and stakeholder engagement; in one instance the requester proceeded with production without separate license clearance. For institutionally provided assets, requesters were referred to the Media Production team and informed that the IU Brand Hub existed as a brand asset source but carried its own usage restrictions. Located contract excerpts, vendor guidance, and notes from stakeholder outreach were shared with requesters; unresolved questions about bulk download, persistent storage, API access, or redistribution were handled via formal escalation to vendor account teams and legal review when written permission or explicit contract language was required.

The requester was provided with KEKA as an alternative macOS archive extractor via the institution's Software beziehen (Service Portal). The user downloaded KEKA and confirmed it successfully extracted the ZIP archives and allowed viewing the EXE file contents; the ticket was closed after verification. 7-Zip remained unsuitable for the macOS environment in this case.

The issue was resolved by using an updated vendor checkout flow: the course vendor replaced the broken Stripe checkout link and restored the license-selection/banner UI. Stripe-side card-processing throttling had temporarily prevented successful transactions; once the vendor re-enabled the corrected checkout URL and the card-volume subsided, the purchaser retried with the appropriate cost-center/payment details and completed registration and license assignment.

Licenses and installers had been provisioned from the central IT license inventory and delivered via Company Portal distribution-group membership, one-time clickable links, or direct inventory allocation; Pro, Team Cloud, Team/Network and Education records were created with required add-ons and durations and recorded. Team/Network simultaneous-edit projects received named-user Team/Network licenses and project-level simultaneous-editing was configured during scheduled setup. When licenses approached expiry or were reported expired, team members redistributed usable MaxQDA license keys to affected users so keys could be entered to reactivate access; inventory inconsistencies were resolved by reviewing entry states and comment fields to locate and reallocate usable keys, and internal staff applied allocations when on-site staff lacked inventory access. Assignment changes were applied through inventory allocation and Company Portal distribution-group membership rather than altering Okta provisioning; renewal dates and Okta-managed assignment notes were recorded. Previously reported license-server assignment faults were identified and corrected and normal operation resumed. Installers were confirmed downloadable without endpoint admin rights but required a valid license/key to run; incorrect packaged product versions were removed from endpoints and packaging/inventory and the correct product/version was integrated, packaged, released, and recorded. For vendor-managed licensing workflows (for example, Sofistik with Codemeter), users without a vendor-issued license were directed to the vendor’s license-request process while internal support provided inventory guidance; for vendor-supplied network license files (for example, Ansys), administrators placed the vendor license file on the license server and recorded the addition in the license inventory. When the inventory contained no free licenses, IT engaged procurement and stakeholders to request additional purchases and tracked procurement delays and approver actions while keeping requestors informed until purchased licenses became available. Requesters were advised that MAXQDA is a paid product requiring cost-center approval and purchase for new licenses; Education-license requests were handled through the application/approval workflow (Automation for Jira), approvers were sometimes adjusted in that workflow, setup meetings were scheduled for installation/configuration, and tickets were closed after installation completed. Duplicate or superseded requests were closed when a valid inventory allocation or existing assignment already covered the need.

Access and creation problems were resolved after users received the appropriate Miro tier (Starter, Business, Enterprise) or after account and board permissions were corrected following the Application Request Self‑Service (Jira Service Management) approval workflow. IT processed approvals (including Automation for Jira where used) and assigned paid/full or free‑restricted licenses; in some cases automated assignments appeared in audit logs as “Atlassian Api User” and restored edit access. The Free/view‑only “you need to upgrade” banner often persisted until users signed in through the institution SSO (Okta) and license provisioning propagated (approximately ten minutes) or after re‑authentication. Board‑level access problems were cleared when the board owner re‑added the user. When a paid license appeared present but features remained unavailable, specialists found the license applied in a different Miro organization/environment; those cases were resolved by reassigning the license to the correct team environment, moving the user/team into the Enterprise environment, revoking and reassigning the license, or escalating to the Miro admin. Requests that lacked the correct approver remained pending and were auto‑declined or closed by Automation for Jira when approvers did not act (one recorded auto‑decline occurred after 14 days); users were informed to resubmit including the appropriate approver (typically the team lead or cost‑center manager). IT confirmed that Education‑tier Miro licenses did not support SSO/MFA while Business/paid tiers supported SSO. Tickets were closed after verifying license state; some records contained only an automated assignment entry and lacked explicit human-confirmation of the outcome.

Access failures were traced to missing, incorrect or not‑yet‑provisioned Power BI/Microsoft 365 licenses on Azure AD accounts. Administrators provisioned and assigned the appropriate entitlements (Power BI Pro, Premium Per User/PPU, Premium Pro, or the correct Microsoft 365 SKU such as Office A5) and, once provisioning completed, users regained access to previously restricted datasets, Premium features and report usage metrics. Several incidents involved license requests left pending or auto‑declined by cost‑centre approval workflows (tracked by Automation for Jira); requests were sometimes declined because the wrong cost centre was selected or reviewers misclassified the entitlement need. One incident involved account internalization where an external/free/trial license (and an old external email) remained on the account; replacing that with the correct Microsoft 365 (Office A5) license restored dashboard access. Another incident showed Okta provisioning Microsoft A1 without assigning the dependent Power BI Pro SKU (IUG-AAD-ASS-License-IT-PowerBI-Pro); manually assigning that Power BI Pro license to the affected user/group restored access. In some cases users could not request Power BI because the license‑request form did not list Power BI/Power BI Pro in the software dropdown; those cases required an administrator to correct the request metadata or manually assign the entitlement. Assigning the correct licenses also removed in‑app upgrade prompts (the “Run”/“ausführen” button) without requiring users to accept the prompt.

Requests were normally submitted through the IT Service Portal and routed to Automation for Jira approval chains; when approvers completed approvals downstream vendor/onboarding workflows delivered invites and licenses and access was granted (confirmed for Zapier and n8n). Automation for Jira sometimes detected a missing or unavailable approver and automatically declined or closed approval tickets with messages such as "your ticket is missing the approver" or "14 not approved or approver no longer available"; those tickets were recorded as declined and required manual escalation to specialist teams to restore or reprocess the request. Where the software catalog lacked an appropriate product choice (for example Circleback not selectable), requests were escalated to specialists who clarified the requested product with the requester and corrected the routing; if no reply was recorded tickets could be auto-closed after the standard inactivity timeout (typically 14 days). Procurement-type requests required inventory checks, a named business use-case, and identification of internal subject-matter/academic support (fachliche Betreuung) before purchase; some purchase requests were declined or substituted with approved alternatives (example: Teleprompter Pro replaced by a CapCut upgrade). In cases handled by specialists a license or invite was directly issued and recorded (for example a Laravel Herd Pro license was assigned with license ID 74AE6A75-33AB-4AF9-A2D5-08301644D6B9) and the ticket was marked done. Some requests were closed after confirming the software was freely available to end users and did not require IT approval (example: Efficient Elements for PowerPoint).

License and access requests were processed through Automation for Jira approval workflows that assigned cost-center or C‑level approvers and issued reminder notifications. When required approvers did not act, approvers suspended reminders, or requests were marked obsolete/Won't Do, Automation for Jira automatically marked the request as declined or the ticket later auto-closed for inactivity after the configured 14‑day approval window. Some requests explicitly requested a specific SKU and cited high monthly costs (examples used by requesters included ≈€200/month), which triggered C‑level/cost-center approval requirements and created ambiguity about the designated approver. In multiple cases SKU/feature naming caused unnecessary escalation — for example, a requested Deep Research capability was available via ChatGPT Plus at a much lower published price (~$20/month), prompting users to ask whether they could buy privately and expense the purchase. When approvers approved corporate/team requests, admins sent product invitations and closed the tickets; admins also occasionally sent invitations proactively and advised recipients to check spam folders when delivery issues were reported. Product availability and usage quotas constrained offerings: ChatGPT Pro was sometimes unavailable and only a Team license could be provided, and Team licenses occasionally hit usage limits quickly and blocked user workloads; admins resolved quota blocks by provisioning additional Team licenses and sending invites. The primary failure modes were stalled or unattended approval workflows, ambiguity about the required approver for Pro-level purchases, SKU/feature naming confusion and cost-miscommunication, invitation delivery failures, and licensing availability/quotas.

Requests for paid SaaS/IDE/training seats, credit‑based or trial licenses, product upgrades, vendor invitations, or license/admin changes were processed through the organization’s procurement and approval workflows, Application Request/Automation for Jira, or routed to the internal product owner or specialist teams. Approvals and cost‑center charges were recorded with approver contacts and invoice details; provisioning was completed and tickets were closed after confirmation or, when requesters did not respond, Automation-for-Jira auto‑closed the ticket with a short reopen window. Requests for services owned by other internal teams were redirected to those teams’ portals (for example, DevOps provisioned GitHub Copilot after a DevOps‑portal request and Automation‑for‑Jira approval). Vendor access was provisioned by issuing invites or forwarding vendor registration links for self‑registration when permitted; some vendors required person‑based accounts (Canva was confirmed person‑based) and shared‑account workarounds were used where allowed. Vendor selection and procurement included technical suitability checks and business justification (example: a Mailosaur/MailSlurp evaluation driven by the need for multiple durable inboxes >24 hours rather than short‑lifespan temporary addresses). Credit‑based licenses were allocated between courses or users (example: HeyGen Creator credits). Non‑packaged or locally activated software was installed and activated manually or during scheduled remote sessions over VPN and TeamViewer QuickSupport (example: memoq v10→v11 update). Okta SSO‑provisioned logins and license assignments were verified and corrected when needed. Procurement triage captured licensing nuances such as site additions forcing tier upgrades, team/shared‑account concurrency limits, supervisor/approver requirements, and cost/price discrepancies; stalled requests were escalated or re‑triaged and procurement/contracting delays were documented until resolution. Requests were canceled when the requester departed before completion and accounts were later deprovisioned after role changes when applicable. Products handled included GitHub Copilot, Vectorworks, CapCut, JetBrains (WebStorm, PhpStorm, PyCharm, DataGrip, all‑products pack), HeyGen, DeepL Pro, JungleMail, Freepik, Cloudcraft, Mouseflow, Kahoot/Kahoot+ for Higher Education, memoq, Canva Pro, Pluralsight, Mailosaur, MailSlurp, Mentimeter, and common enterprise tools.

Support reissued the Standard Overleaf license by sending a new invitation to the user's Overleaf account, restoring the user's collaborative access. The ticket was marked complete after the license was reassigned.

Requests entered the Jira Application Request / Service Portal approval workflow and were repeatedly notified by Automation for Jira until the configured approval window elapsed; when no valid approval action was recorded the automation marked tickets Declined or auto‑closed (commonly after 14 days). Resolutions observed included: correcting approver records or cost‑center assignments so the correct manager could act; restoring approver accounts or group visibility so approvals registered in Jira; and clarifying that only the Jira/Service Portal approval action counted (approvals posted solely in ticket comments, email or other channels did not prevent auto‑closure). Several requests had stalled behind formal security or data‑protection reviews; support coordinated with Cyber Security Services and IU Datenschutz and procurement proceeded only after documented signoff or confirmation of required product tier (for example Weavy/Figma team plans lacking admin controls required Enterprise tiers). Ambiguous or incorrect entries in internal license inventories (for example unclear links or unexpected durations in iug.enteksystems) had caused confusion; correcting those records allowed tickets to be completed or appropriately closed. In cases where an approver needed prompting, support requested that the manager submit approval via the Service Portal and clarified ambiguous product choices (for example free vs licensed Adobe Reader variants). Where a valid license already existed support verified it and closed the request as done; where trials were appropriate support supplied vendor trial downloads/activation instructions and, when manual key entry was required, used short TeamViewer QuickSupport sessions to activate trials. Some long‑inactive requests were closed during a post‑Minerva cleanup and requesters were instructed to raise a new ticket with a reference; other tickets were closed as "Won't Do" when requesters procured licenses privately or no Jira‑recorded approval existed and the approval window lapsed. Several Adobe Acrobat/Creative Cloud and other enterprise license requests (think‑cell, Overleaf, Weavy/Figma, Microsoft 365 and others) were affected by these approval/workflow failures.

Requests for vendor‑hosted subscriptions, APIs, or Office Store add‑ins that required vendor‑side payment or contract changes were routed to applications/licensing and procurement teams to check for existing institutional or enterprise accounts, applicable discount codes, invoicing options, and entitlement scope. When vendors deprecated marketplace distributions procurement migrated contracts from the marketplace to direct vendor agreements so API access was retained and related marketplace/AWS accounts could be closed (example: Adobe PDF Services). For offerings that required manual vendor‑site upgrades support arranged joint sessions so requesters could complete registration and enter payment details; examples included ElevenLabs Starter and ChatGPT Plus (one ChatGPT Plus attempt was blocked by an institutional stored‑card limit). Invoice billing and payment methods were configured where supported; a DeepL Free account was upgraded to DeepL API Pro and invoice payment was set during a scheduled session. In cases where provisioning behavior could not be managed centrally cases were escalated to product specialists and to Microsoft support to troubleshoot Office Store provisioning; Zebra BI Charts for Office was confirmed to be a third‑party Office Store add‑in that could not be added to Azure AD license management and the requester could not purchase without a corporate/corporate‑card payment method. When no external procurement path existed requesters were directed to licensing/procurement or offered internal alternatives or seats (example: Julius.ai).

Support confirmed that Jira licenses for the instance did not automatically expire and identified which team members required licenses. The pending license requests were approved and the accounts were provisioned; the specific user without access (Eva Fürst) received a license and access was verified as restored.

The user was enrolled in the IU Learning Hub course 'Copilot for M365 Essentials'; completion of that course triggered automatic assignment of the Copilot for M365 license without a separate notification. After the license was assigned, up to 72 hours were allowed for Copilot features to become available in Microsoft 365 apps. The 'Could not connect to MS Graph Api.' message (including occurrences reported by Automation for Jira) was observed while the license/features were not yet active. It was recorded that Copilot for M365 licenses were not currently available to employees directly employed by IU Internationale Hochschule GmbH because of an ongoing consultation with the works council, and that rollout to LIBF and UFred was being examined separately.

Activation was completed by supplying and entering a valid Windows product key into the virtual Windows instance running in Parallels on macOS. In one case a Multiple Activation Key (MAK) was entered directly into the VM by support; in another case a product key had been provided to the user via Microsoft Teams. The Parallels Desktop license had already been supplied separately and was not the cause of the activation failure.

Affected users were enrolled in the IU Learning Hub self-learning course "Copilot for M365 Essentials" and tenant automation was configured to assign Copilot for M365 licenses after course status changed to "completed." When certificate uploads during a Learning Hub/platform transition left course status incomplete, support confirmed which modules were missing, users completed the outstanding items, and licenses were assigned after the status updated. Support identified requests that had been submitted via non‑designated intake channels (for example Automation for Jira / Atlassian Service Desk) or that were routed to incorrect approvers; approver assignments were corrected and users were directed to start the designated "Copilot for M365" IT Service Portal form so the automated workflow could process the request. Where automation failed to add users to the licensing group, support re‑enrolled users or performed manual group assignment. Support also identified that some employer affiliations or staged‑rollout exclusions (for example IU Internationale Hochschule, LIBF and UFred extensions, and Hochschule GmbH) were not eligible or required clarification and therefore blocked access to the portal form or provisioning. After assignment, license and Copilot feature availability in Microsoft 365 apps (and in one report, Copilot for M365 Space) were observed to take up to 72 hours to propagate. No separate notification was sent to users when the license was provisioned.

Support identified two distinct root causes that produced identical desktop app license symptoms. For external/lecturer/contractor accounts, administrators reassigned affected accounts from an A1Plus (desktop‑app entitlement) SKU to an A1/web‑only SKU (change effective 2024-08-31 in at least one case); users saw installer or runtime messages including "You do not currently have an Office license assigned that includes the Office desktop apps" and were unable to download or run Office desktop apps while office.com and mail via campus SSO remained available. Support notified affected users and advised use of Office for the web (office.com) and web mail; central IT treated the entitlement removal as an academic licensing decision and did not perform broad reinstatement of A1Plus (restoration was evaluated in at least one case but not applied because the license was scheduled to expire). Separately, some incidents with the same user‑facing errors were caused by on‑device legacy/perpetual Office installations (reported as Office 2016) that had lost activation; those cases were resolved by deploying the current Office package from the Intune Company Portal and removing the old Office 2016 installation so desktop apps reactivated and Outlook stopped crashing. One ticket also reported a missing training video that was not attributable to the Microsoft license change and had no definitive source identified during that investigation.

Parallels license activation was handled separately: an activation key was delivered to the user via the SAFE portal and the user confirmed Parallels Desktop Pro activated successfully. The Microsoft 365 sign-in failures were resolved by removing stale authentication state and replacing the IU-specific Teams package with the Microsoft 365-compatible client. Specifically, stale Office/ADAL credentials were cleared and Office Click-to-Run repair was run to refresh AAD authentication tokens; the IU-Akademie Teams MSI was uninstalled and the per-user 64-bit Microsoft Teams "work or school" desktop client (from the Microsoft/Teams download portal) was installed. After these actions, Office apps authenticated consistently, Outlook/Word stopped showing intermittent sign-in failures, and the user was able to sign into the Teams desktop client with the external ext@iu.org account.

Incidents were resolved after user entitlements for Acrobat Pro were present in the Adobe Admin Console and Acrobat was reprovisioned or reinstalled. In many cases signing out of the Adobe desktop app and signing back in refreshed the user’s license/session and restored Pro features without a full reinstall. When the Creative Cloud installation path was used, Acrobat needed to be installed from the Creative Cloud app for files to launch in Acrobat via the Creative Cloud association; on some endpoints Acrobat Reader had to be removed first so Acrobat would appear in the Creative Cloud app and be installable. Support agents manually removed Adobe components on machines where Acrobat Reader was being incorrectly recognized as the full product or where uninstaller processes aborted; functionality returned after license allocation completed and Acrobat was reprovisioned/reinstalled. Non‑admin installs delivered via Company Portal, Self‑Service, or Software Center displayed Reader/annotation capabilities when Pro entitlements were not yet allocated and required reprovisioning after entitlement allocation to regain Pro functionality. Attempts to substitute third‑party PDF utilities (for example PDF24 or PDF XChange) did not provide Acrobat Pro editing or conversion features. In one case procurement policy prevented approval of a private PDF XChange Editor license and Adobe Creative Cloud (which includes Acrobat Pro) was offered and assigned as the supported alternative.

Expired or renewed think‑cell licenses were resolved either by activating a renewed license key in the think‑cell activation dialog inside PowerPoint or Excel or by allowing the product’s automated renewal to complete at the expiration date (confirmed by licensing). Support commonly applied keys during brief remote sessions (frequently using TeamViewer over VPN), transmitted keys to users via Microsoft Teams or SafeLink, and recorded activated keys in the license inventory. When the add‑in had been removed or was not available in Company Portal (Intune), support provided the new key to the user and escalated the incident to Intune/software‑deployment for re‑provisioning or synchronization; large rollouts used Intune update groups and machines that were powered off or offline remained pending until they came online. Renewal requests and issuance of new keys were sometimes forwarded to Business Operations/licensing and support followed up to confirm activation; tickets were occasionally closed automatically for inactivity or when the request had been misfiled. Agents redirected misrouted renewal requests and instructed users to open Think‑cell renewal tickets in the Jira Service Management IT Service Portal for proper processing. License‑inventory anomalies (for example, counts exceeding licensed seats or apparent shortages during staged deployments) were recorded for reconciliation. Tickets where users declined or could not provide remote‑access credentials were closed without installation. Incidents rarely included specific error codes.

A Power Automate (Flow) was created and implemented to monitor Okta A1/A5 license usage and generate forecast/notification alerts. The Flow was reviewed and improved in collaboration with the named recipient, configured to send notifications to that recipient, and documented. An extension to also post alerts to the CPC Microsoft Teams channel was planned and noted in the documentation.

Support responded with tailored guidance that contrasted personal Microsoft 365 subscriptions versus perpetual Office 2021 licenses and explained that the exact recommendation depended on which Office apps and plan the instructor required. The instructor was informed of the licensing differences and the factors to consider when selecting and purchasing a personal license to maintain continuity after the institutional account ended.

IT Engineering was contacted to confirm ownership and process; Florian Regente was identified as the approver/responsible person for the Apple Developer Program license. Procurement and payment details were clarified with the approver and the purchase was handled through the confirmed corporate process, allowing the macOS/iOS packaging requirement to be covered.

Access failures were resolved by addressing two distinct root causes. For cases where a user account or active license was missing, support submitted a software/license request, took ownership of the ticket, and scheduled/confirmed license assignment through the approval workflow; once the license was provisioned the portal content and sign‑in succeeded. For cases reporting "license" or "license retrieval" errors, investigations found vendor-side license checks failing due to network-side restrictions or reliance on a vendor-supplied connection client. Those incidents were resolved by restoring vendor connectivity and completing required approvals: network/proxy/port rules were adjusted or the vendor-recommended client (Akamai Zero Trust Client) was approved and deployed after IT Security/Legal reviewed telemetry/data-processing concerns. Some incidents combined both causes (unassigned license plus blocked license retrieval); resolution required both license provisioning and enabling the vendor connectivity. Support coordination with the vendor, IT Security, and Legal/Procurement was documented as part of the remediation.

The missing commercial impact was quantified and documented: a one-time fee of approximately €5,000 and an estimated annual license cost increase up to ~€15,000 for a ~30,000-student scope. The cost estimates and scope change were escalated to procurement and approval channels so a formal purchase/contract amendment for the Push Export capability could be initiated while the integration remained operational.

Current license keys or serial numbers were supplied to users so installations and activations completed. Where an installed copy was paired with a key that was invalid for that version, support identified the version/key mismatch, obtained the matching installer and the current software key, and arranged for the package to be updated or reinstalled. For think‑cell, users were pointed to the think‑cell portal (server.think‑cell.com) and instructed to use their institutional email (IU‑Mail) to receive the download/link; support also offered to enter the license key or perform the installation for the user. For company‑portal installations using education licenses (for example, Vectorworks), teaching staff obtained the education serial number through the institution’s licensing portal or licensing team and supplied that serial during installation. Where applying a new key or reinstall required administrative rights, IT performed the installation or temporary elevation was granted; after installing the correct version and applying the matching key, activation succeeded.

Investigation found no known IU corporate license for the Decisions Teams app. The support contact asked the requester to provide names of current users for follow-up, provided the vendor representative contact (Laura Brieden, phone +49 89262042680) for licensing discussions, and offered to schedule a meeting to discuss institutional needs.

No license increase or procurement action was documented in the ticket. A short meeting was proposed to discuss next steps (comment by Oleg Medvedev to set up a meeting the following week); the ticket was marked Done without recorded license procurement.

Procurement and IT documented the finalized license mapping and audited tenant configurations. The organization purchased Microsoft 365 A5 for staff and A1 for eligible students; Copilot features and several Viva add‑ons were identified as separate add‑ons or SKU entitlements and were not included by default. The "learning accelerators" referenced in documentation were third‑party/Teams apps available through the Teams app catalogue that had not been tenant‑wide deployed; Teams app permission and app setup policies in the Teams admin center were used to block or enable apps and those policies were scoped to Azure AD groups so controls were applied per user cohort. Azure AD PIM was enabled for privileged roles; current PIM settings used eligible (not permanent) assignments with activation workflows that required MFA and justification before elevation. A 30‑day audit was run across Microsoft Purview/Audit logs, Azure AD sign‑in logs and Teams audit records; no evidence was found of third‑party access to the specified works‑council mailboxes, Teams channels or chat items during that window. Windows 11 enterprise telemetry was confirmed to be governed by Intune/Group Policy settings (tenant set to enterprise/security level) and Windows Hello biometric templates were stored locally in the device TPM and were not transmitted to Microsoft or third parties. Relevant configuration exports and audit log excerpts were provided to the requestor for review.

Support reproduced the error and confirmed the root cause was entitlement/tenant settings rather than the Intune install. Troubleshooting verified the user's M365 license presence and then checked tenant app enablement. The case was resolved by confirming the user had the appropriate M365 SKU and that Clipchamp had been enabled for the organization in the tenant application settings; once the entitlement/tenant setting was corrected the Clipchamp desktop and web app launches worked as expected.

IT confirmed and re-assigned the paid Figma license in the admin portal and instructed the user to sign out and back in. When the entitlement did not materialize in the user's session, IT escalated the case to Figma support and opened a vendor ticket; the vendor-side intervention and license re-assignment resolved the discrepancy and restored full-plan access for the user.

Support verified mailbox activity and then confirmed that the A1 entitlement in use did not include desktop Office activation. The investigation concluded the instructor's visible mailbox license was not sufficient to activate installed Office on a local machine, and the inability to activate was due to the A1 SKU's license limitations rather than a configuration error.

Inventory lookups (Inv360) and ticket follow‑ups were used to determine per‑tool ownership and the correct procurement/contact paths rather than assuming a single central owner. For Slido and Mentimeter, Inv360 records showed Library and Information Services (LIS) as the last recorded owning team, and the License Team and LIS were identified as the contact points for assigning or purchasing paid seats; external lecturers were generally expected to use free/personal accounts, and an approver confirmed that external Mentimeter licenses had been denied in the past and were not being granted in that case, with the ticket subsequently marked declined and auto‑closed by Jira automation. For Articulate 360, existing licenses were reserved for Learning Hub Key Users; Key User requests were handled via people‑projects@iu.org and non‑Key‑User requests required a new business case and review. Requests for GitHub offerings (Codespaces) and Repl.it were forwarded to faculty contacts; a faculty contact confirmed GitHub Codespaces was excluded/not currently available, and IT Operations indicated they handled licensing questions but did not hold direct GitHub admin access, leaving procurement or availability unresolved. Where ownership and procurement paths were identified, requesters coordinated with the owning teams or faculty contacts; where ownership or availability remained unclear, tickets recorded the forwarding actions, the identified contact who would need to approve or purchase seats, and any automated declines or closures that occurred.

Support reviewed licensing and procurement records and confirmed the MAXQDA transcription add-on (MAXQDA KI / f4) required an assigned MAXQDA license key, a valid internal cost-center (CC15200), and correct entries in the IU SAFE APP/billing before the add-on could be purchased and provisioned. Support issued the user’s license key and recorded the provided cost center (CC15200), and documented that a designated approver’s release was pending (ticket referenced approver names). The user was informed that the MAXQDA installer appears in the Company Portal (Unternehmensportal) on Windows (searching for “maxqda”) and that SharePoint/portal availability depended on the procurement/approval and billing entries being completed.

IT confirmed they did not own or manage the website or promotional discount system, informed the requester that the service desk could not handle the website/promotion inquiry, and directed the requester to file the issue through the IU Meldeportal (Jira Service Management atlassian.net). The ticket was closed after the requester was routed to the appropriate portal for the website/product team to investigate the invalid code.

The request was forwarded to the team responsible for Microsoft licensing. The Power BI Premium license was provisioned and assigned to the user by the licensing administrator (assigned by Adrian on 2024-04-19), restoring the user's Premium entitlement.

Investigation showed Adobe Sign sent workflow notifications from Adobe's system sender rather than masquerading as the individual IU user, and Automatic Delegation required a licensed Adobe Sign user account (it could not directly point to an unlicensed shared mailbox). The issue was resolved by delivering copies of agreement-related messages to the shared address: agreements were configured to add the shared mailbox as a CC/additional recipient or the tenant-level notification forwarding was used to copy unternehmen@iu.org. Where post-delivery routing by Twilio required a stable sender address, Twilio was configured to accept and route messages from Adobe Sign's system sender instead of expecting the individual user's IU address. Alternatively, a dedicated Adobe Sign user account tied to the shared mailbox was created when full in-product delegation semantics were needed.

The incident was resolved by coordinating vendor billing and LMS entitlement changes. Vendor support removed the private credit card and migrated the subscription to the institution/procurement-managed billing method, and the vendor changed the account ownership so the ShowMe premium entitlement was tied to the user’s institutional identity rather than the colleague’s payment method. Separately, MyCampus course enrollment/permissions were corrected so the user had upload rights for the target courses. After these changes the user’s ShowMe premium features were available and uploads to the required MyCampus courses succeeded.