mirror of
https://github.com/massgravel/Microsoft-Activation-Scripts.git
synced 2026-04-26 22:45:50 +03:00
[GH-ISSUE #619] [Feature Request] APPXBUNDLE Desktop Office #407
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Microsoft-Activation-Scripts#407
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @moriel5 on GitHub (Oct 12, 2024).
Original GitHub issue: https://github.com/massgravel/Microsoft-Activation-Scripts/issues/619
Currently, the Microsoft App Store Desktop Office suite is recognized as the UWP Office suite... despite not really being UWP, just packaged as .appxbundles with the individual apps recognized by the OS as extensions of the base package (there are 3 "UWP" suites, this one, which is not UWP, the arm32 Office RT suite and the Office Hub).
Is there anything preventing supporting this Desktop Office suite?
OfficeRTool supports it just fine on Windows 10 (unless something broke in the latest versions, since it does not recognize it on a brand new Windows 11 LTSC IoT install).
@moriel5 commented on GitHub (Oct 12, 2024):
Thanks for the quick answer.
That is certainly surprising, since aside from a few (very few) hiccups, I have not seen any issues over the past 6+ years when activating via OfficeRTool (and I have installed and activated this specific Office suite many times over that timeperiod, for pretty much anyone who I set up a Windows PC (desktop, laptop, tablet) for, which is a few tens of people, at a ratio of around 2.5 devices per person (some more), including clean reinstallations with newer Windows 10 versions.
@moriel5 commented on GitHub (Oct 12, 2024):
Manually.
I download the packages via the ADGuard website interface to the store (the CategoryID is required), and install them via the graphical Package Installer (I still need to find time to figure out how to conduct a system-wide installation), as the individual app packages have to be installed simultaneously, and right after the base package.
To activate them, I convert the license model from C2R to VL, and activate via KMS (as ohook wasn't present in the OfficeRTool version I was using last time I needed to do so, or I did not notice the addition).
And aside from extremely rare situations (perhaps 5 in total over the past 6+ years, on two occasions), updates have never broken the activation status.
@moriel5 commented on GitHub (Oct 12, 2024):
Again, I am surprised, as I see no difference between the two, except that this version is much more easier to manage, as a technician, and draws less system resources (marginally, there are less background services, as all updates are managed via the store, which do work automatically as expected), and leaves next to no residue, even without scrubbing (so I can easily uninstall and reinstall without any worries in regards to what was there first).
Also, whether activating unofficially or officially (whether by standard license or by account, either of which determines the version and edition), there is no functional difference that I have perceived (yes, I have done both, depending upon whether it was a customer or someone I personally knew who was alright with it).
@moriel5 commented on GitHub (Oct 12, 2024):
Thanks, that certainly makes sense.
@moriel5 commented on GitHub (Oct 28, 2024):
I'll make sure to test it soon, as I am just to about to prepare a few more machines.
@moriel5 commented on GitHub (Dec 23, 2024):
Sorry this took so long.
I have since tested this on multiple different devices, in multiple location, both on Windows 10 and 11, and so far, not a single issue has cropped up since then, on any of those devices.