M365 Apps for Business on Server 2019 VDA asks Users for "signing in to set up Office"

[Bernd Baedermann1709162314]

Hello all,

 

we're facing a small issue whit M365 Apps for Businness on Server 2019 VDA.

When a user logs in for a first time on the Worker, a new Profile Container (FSL) is created.

When the users starts Outlook he gets the dialog withc the pre-populated email adress and he can log-in to M365 Services.

SSO is working at this stage (AD Connect is configured with PTA) and the user is logged in without entering his password.

 

BUT: After the M365 App is starting a new dialgog appears:

 

Shared Computer Activation (SLC) is activated and I can see those registration txt files are created.

When the Users logs off an on again, it works like a charm. 

 

Does anyone know how to prevent this pop-up when initially launichg an M365 App for the first time?

 

[Jonathan Pitre]

This is a known issue on Server 2019.

Please read the following:
https://discussions.citrix.com/topic/403721-office-365-pro-plus-shared-activation-password-screen-not-able-to-select/page/9

https://docs.microsoft.com/en-us/office365/troubleshoot/authentication/automatic-authentication-fails

Add the following PowerShell code to a user login script and it should fix your issue.

If (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin

 

[Bernd Baedermann1709162314]

Hello Jonathan,

 

thank you for your answer, but that doesn't work for me.

 

As mentioned in the discussions you've shared, I created a cmd as published app and check the user state with dscmdreg while a clean-fresh profile is created:

 +----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+

                    NgcSet : NO
           WorkplaceJoined : NO
             WamDefaultSet : NO

 

I run the powershell command mentioned in the article and check again the user state:

+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+

                    NgcSet : NO
           WorkplaceJoined : NO
             WamDefaultSet : YES
       WamDefaultAuthority : organizations
              WamDefaultId : https://login.microsoft.com
            WamDefaultGUID : {yxz} (AzureAd)

 

Now I start Outlook as published application:

-  I get the Window with my prepopulated email adress and I click on "Connect" button

-  After approx. 5 seconds, I get the message that "Something went wrong". I re-tried a couple of times but alwas the same message. 

 

When I add those Registry keys (which are not recommended by MS) Outlook will create my mailbox and office is activated:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\DisableADALatopWAMOverride 

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\DisableAADWAM

 

BUT: I still get the message "Sign in to setup Office" like I wrote in my initial post above. 

IMPORTANT: I get this message also when I start a published Desktop and configure Outlook for the first time.

 

So I get this message in Outlook as published app, as well as Outlook via published Desktop. When I close this message, Outlook is fully activated and I can work with it. 

 

 

 

 

 

 

 

 

 

 

 

 

 

[Wendell Pinegar]

On 10/13/2021 at 2:35 PM, Jonathan Pitre said:

This is a known issue on Server 2019.

Please read the following:
https://discussions.citrix.com/topic/403721-office-365-pro-plus-shared-activation-password-screen-not-able-to-select/page/9

https://docs.microsoft.com/en-us/office365/troubleshoot/authentication/automatic-authentication-fails

Add the following PowerShell code to a user login script and it should fix your issue.

If (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin

 

 

Thanks for your post. It helped resolve an issue we were having with Office 365 published apps not activating. Your fix was accurate and resolved the issue. We also found that Office 365 was locking up when it was running as a published app. We had to disable Office 2016 hardware graphics acceleration via GPO to resolve that particular issue. 

[Ryan Gallier]

Is this still the only workaround?  There is no "real fix" yet?  

 

Thanks.