As I have recounted in a preceding series of posts on this site, starting in mid-January and lasting some few weeks I encountered various weird issues with Office 365. Here’s a list of those posts in chronological order, oldest first:
No matter what I did or tricks I essayed, Office remained activated for five days after each fresh install. Then, it deactivated itself and would not let me re-activate for love or money. In addition, connected Azure AD / Office 365 accounts showed Account error constantly, and wouldn’t connect to services such as SharePoint or OneDrive for Business. As a result, Office 365 components (Word, Excel, and so forth) remained unusable on my laptop for weeks. Because I had so much to do, I settled for using Office Online instead.
Office Activation Issues and Resolution
For some reason, however I built my deployment images, after activating with Azure AD credentials Office always showed two licenses presen. One of these would be a licensed Click-to-Run or an MSI installation (yellow highlight in the following screenshot), the other a “Grace Edition”, a five-day trial (blue highlight below):
After deploying a new Windows image containing Office it simply stopped working after five days. I’d be prompted to activate Office, but the account dialog would neither accept my Azure AD credentials nor a valid product key. In fact, I could not find any factual reason for this behaviour. Even so, I have strong reasons to believe that the conflicting Grace Edition appears because of how I make my deployment images. I customize Windows in Audit Mode signing in as the built-in admin, install software including Office but don’t activate it, then sysprep and capture either a WIM or FFU image. Finally, I deploy that image to my target PC. The end user — myself, in this case — then activates Office by signing in using Azure AD credentials.
Upon closer inspection, it looks as if the original install of Office was flagged and is what appears as the five-day Grace Edition. That meant I had to come up with some way to avoid the issue of adding a licensed version of office that the image, once deployed, would not “see” or register.
I don’t mean to say this is what you should do if you ever face the same issue. I am simply saying this is the solution that worked for me. First, I decided not to include Office in the deployment image — that is, not to install it in Audit Mode before sysprep. Office installation is relatively fast, so I have nothing against installing it after deployment. This worked for the activation issues. Today, Office remains activated and usable long after the five-day grace period has expired simply because that SKU is not present anymore. In fact, I’ve now repeated this procedure several times and have had no activation issues since making that change to my installation steps.
Activation issues resolved.
Account Error Issues and Resolution
These items proved somewhat trickier than my problems with activation. Even after I fixed activation simply by omitting Office from the deployment image, both of my primary Azure AD accounts threw an Account error, and wouldn’t allow me to use connected services. For one thing, I couldn’t sign in to SharePoint:
I have had these Account errors for a long time now. They occur every now and then, when I notice that I am signed out from all Azure AD accounts in Office and can’t sign back in again. This has not only baffled me but it has also flummoxed Office support. After resolving my activation issues, I decided I wanted to fix this, too.
As you already know, Microsoft no longer allows using your Azure AD email as “existing email” when creating a new Microsoft Account:
However, at the time I’d obtained my workplace Azure AD accounts, such sign-up was still possible. Thus, I created a new Microsoft account for each of my Azure AD accounts. That explains how I had a workplace account named kari@AnyDomain.com, and a Microsoft account named kari@AnyDomain.com, each with a different password. In retrospect, I now understand that this was an abysmally stupid idea.
Once again, I re-checked my accounts and connected services in Word. That’s when I finally noticed a problem — or rather, when I really saw that problem for the first time — while looking at my connected personal OneDrive accounts in that list. Aha! The same email address appears for a personal OneDrive as a Microsoft Account that connects to Office without any issues. But the same email address as Azure AD account tries and fails to connect to OneDrive for Business and SharePoint.
A quick test: I visited https://account.microsoft.com. I created a new outlook.com email alias for one of these Microsoft accounts currently using an Azure AD email address. Then, I made the new alias the primary alias, and removed the old alias, the one that shared a common email address with my workplace account.
I restarted Word, went to Account, and clicked the “Fix me” button. Then, to my vast surprise, the account connected without any difficulty or errors!
The rest was easy. One by one, I removed these Microsoft account aliases that used an Azure AD email address. I replaced all of them with new outlook.com addresses. One by one, all my Azure AD accounts connected to Office. I’ve had no account errors since making those changes. Go figure.
All’s well that ends well! And I certainly hope that this situation is finally and properly resolved.
Author: Kari Finn
A former Windows Insider MVP, Kari started in computing in the mid 80’s writing code for VAX / VMS systems. Since then, he’s worked in a variety of IT positions. He specializes in Windows image capture, customization, repair and deployment as well as Hyper-V virtualization. Kari is a proud Team Member at number #1 Windows site TenForums.com.