Benzini00

Hello everyone, A bit of a weird one, I'm hoping one of you have come across this before because I'm drawing a blank. We deploy a couple of add-ins for Outlook via the admin centre in Microsoft 365, 'FindTime' and 'Translate Message', we believe the add-in's were working fine before Christmas but now fail to load giving the following error: This add-in could not be started. Close this dialogue to ignore the problem or click "Restart" to try again. When clicking 'Restart' the add-in gives the impression of attempting to load but nothing actually happens. The strange thing is, the 'Insights' add-in loads without any issue. I've trawled the web and followed all the troubleshooting steps I can find, such as, ensuring protected mode is enabled in IE11 settings, ensuring the Office desktop apps and the add-in's are up-to-date, but I can't seem to get the add-in's working or pinpoint the cause of the issue. It feels a bit like a connection error or web rendering issue, we replaced Edge Legacy with Edge Chromium last summer but we're fairly certain the add-ins were still functioning after that change, and with the Insights add-in working I assume that rules out a rendering issue, unless of course the Insights add-in renders differently? Here's what we're running: Windows 10 2004 / Office 13628.20528 (Microsoft 365 Apps for enterprise) / Edge Chromium 89.0.774.57 / Google Chrome 89.0.4389.90 Any suggestions or thoughts will be gratefully received. Many thanks

Hi Garacesh, The furthest we got was Microsoft admitting that UWP apps are pretty much broken when it comes to the use of roaming profiles. During lockdown I investigated our options and found that using FSLogix pretty much resolved the issue due to the way it captures the entire profile rather than just the 'Roaming' aspect, after configuration & testing we took the decision to deploy across our desktops for staff & students, it's all working perfectly so far! ... For mobile/laptop devices we decided to go for local profiles as using FSLogix off-network was too slow across DirectAccess/VPN, the majority of 'important' folders are already redirected to OneDrive and the people using mobile devices typically use the same device on a long term basis and rarely have need to use a desktop device on campus. If you're licensed for FSLogix and have a decent amount of network storage to provision it (typically around 5Gb per user profile, although de-dupe and compression is giving us over 50% savings at the moment) then I'd highly recommend it!

Hi turnerr12, I've pretty much resigned myself to the fact this will never get fixed unless it's taken out of the hands of 1st & 2nd line support, in this case MS seem to have farmed support out to Convergys, unfortunately they're more interested in closing the ticket than resolving it, no doubt because they want their support stats to look good for Microsoft ... I keep being told the issue is with the 'backend team' and then shortly after the ticket is closed and marked as resolved, obviously it's not resolved, so I re-open the ticket and the process repeats. It's now been over a year and the whole experience has been abysmal to say the very least. Please feel free to report your experience to Microsoft and reference our case number, if more people report this hopefully it'll get the attention it requires, our case number is: 119060524001140

Hello everyone, We're currently doing some proof of concept testing around delivering open days during the current restrictions. We decided to use Teams Live Event and it looks like it will do the job perfectly, however, we don't appear to be able to use an external encoder or vision mixer if we choose 'Public' under the event permissions, if we choose 'Org-Wide' or 'People and Groups' we can then choose 'An external app or device' and successfully use an encoder or vision mixer. Does anyone know a way around this? Is this a hard limitation? Many thanks, Benzini00

Hi @Gio_W, Apologies for the delay responding, thanks for posting the code again, it was a formatting issue on my side, doh! The scripts appear to work in terms of allowing the UWP apps to at least open on subsequent logins/different devices when using roaming profiles, however, all UWP apps get reset which means the user will experience first-run conditions, not a deal breaker but it could be annoying if certain UWP apps are used regularly ... I guess this is what happens when UWP app settings aren't stored within the 'Roaming' folder of the users profile though, thanks Microsoft! When using the scripts we're experiencing a long delay during user logon, the user is presented with a black screen for a minute or so before finally seeing the desktop, has anyone else observed this behaviour too? In other news, still nothing back from Microsoft about the roaming profile / UWP issue, has anyone else logged this issue with Microsoft, if so would you mind sharing your case numbers?

Hi all, Still trying to get this issue resolved over 8 months later, Microsoft support keep closing the case and marking it as resolved when it clearly isn't! @LeonC I can't seem to get the second part of your powershell to work, would you mind checking and re-posting? $items = Import-CSV C:\Support\MicrosoftApps.csv foreach ($item in $items) {$foldername = $item.Name Write-Host $item.Name Add-AppxPackage -DisableDevelopmentMode -Register "C:\Program Files\WindowsApps\$foldername\AppxManifest.xml"}

Having not heard anything from MS support for a number of months, despite sending regular emails requesting an update on the ticket, I'm sure you can all imagine my surprise having downloaded build 1909 only to find this issue still exists!

Hello Jessica, I keep regularly chasing Microsoft about this, spoke to them last Thursday, no further news, they keep telling me it's with the 'backend team' and there's no timeline for a fix ... appalling, to say the least. I'll post here as and when their response changes.

Hi jpbp200, Could you detail how you're running both the PS and delprof2.exe in a single script? I think you mentioned earlier on in this thread that you had trouble doing this via GPO, or that it didn't work? Maybe I misread that? Sounds like this would be a good workaround until the Microsoft fix makes an appearance and would mean we can start deployment of 1903.

The 'back-end' team at Microsoft have confirmed they are working on a fix for this issue, no timeline or method of fix delivery is available at this time, one assumes it will get bundled in with one of the monthly Windows Updates. More as and when I hear anything.

I've been testing a few deployments over the last 2 days based upon the findings in the reddit post, at first I was hopeful that the removal of Microsoft Solitaire Collection or the use of DISM to remove unwanted UWP apps from the .wim was causing the issue but sadly that doesn't appear to be the case. Here's what we've tried thus far: 1. Un-modified 1903 .wim - Removed our usual unwanted UWP apps using DISM and left Microsoft Solitaire Collection installed - Deployed with MDT LiteTouch - Same issue, UWP apps open on first login but fail to do so on subsequent logins. 2. Un-modified 1903 .wim - Deployed with MDT LiteTouch - Used a Task Sequence item to run a script to remove UWP apps during 'State Restore' phase leaving Microsoft Solitaire Collection installed - Same issue, UWP apps open on first login but fail to do so on subsequent logins. 3. Un-modified 1903 .wim - Deployed with MDT LiteTouch - Previous Task Sequence script disabled so all UWP apps install - Same issue, UWP apps open on first login but fail to do so on subsequent logins. Having re-read the reddit post it appears the OP was unable to launch UWP apps at all when using a new account, whereas we can launch all UWP apps during the initial session but not during subsequent sessions. Testing continues ...

Oh wow ... I feel the pain of 'kr0k0f4nt' from the reddit post! Right, time to test removing apps during the MDT task sequence rather than directly from the .wim I'm going to follow this as it was mentioned in the comments on the reddit post: https://www.scconfigmgr.com/2019/05/03/remove-built-in-apps-for-windows-10-version-1903/ More shortly ...

Hi BOOT3988, Yes, we've removed it from every build since first deploying Windows 10. Has something changed with that app that you're aware of, dependencies or otherwise?

Hi all, Microsoft are slowly working through the issue, lots of basic troubleshooting which we had already carried out prior to opening our support call, but they obviously need to check for themselves. I mentioned that others were experiencing the same/similar issue, the support engineer, Shipra Singh, told me to share the case number and description so that others can log a call and reference it, this should help speed up resolution as Microsoft will then be able to see it's not an environment, device or build issue specific to ourselves. 119060524001140 In-built UWP apps not working with roaming profiles in Windows 10 1903 I'll post further information as and when progress is made. Many thanks, Benzini00

Hi BOOT3988, Thanks for the link, it's a brutal fix but I can confirm this resolves the issue of UWP apps not opening in 1903. Unfortunately the way the script works is to reset UWP apps on every logon, thus the user will see a black screen for around 10-15 seconds after 'Preparing Desktop' completes whilst it resets the apps, and due to the UWP apps being reset any changes the user makes to those apps during their session will be lost when they next log in. I'm starting to see other reports of issues with the Start Menu/UWP apps so it appears something has definitely changed or is broken in 1903. Still waiting to hear back from Microsoft regarding the ticket I've raised, I'll post here when I've got more information.

Hi @BOOT3988 Are you able to share any information about the tool/script you're using during logon? Many thanks, Benzini00

I spent yesterday creating test users & environments to try and get to the bottom of this issue, as a result of these findings I'm going to log a call with Microsoft as I believe there has been a change/bug introduced to 1903 that wasn't present in 1803. I'll post here with any updates for completeness. Testing process: I have two identical devices, W10-1803 has a fresh install of Windows 10 1803 (the build we've been using for the last 12 months) and W10-1903 has a fresh install of our Windows 10 1903 build Both devices are in the same computer OU within our on-premises AD, thus receiving the same computer GPO's I also created two test accounts, both using roaming profiles, test.1803 & test.1903 both accounts are in the same user OU within our on-premises AD, thus receiving the same user GPO's I logon to W10-1803 with test.1803 and W10-1903 with test.1903 Upon first logon both devices/users behave as expected, all UWP apps launch successfully, Office 365 applications are signed in correctly. I then reboot both devices, this clears the locally cached copy of the user profile due to having the "Delete cached copies of roaming profiles" GPO set. I then log on to the devices ensuring the same user accounts are used with the same devices. On the W10-1803 device all UWP apps open successfully with the exception of the 'Weather' app, which opens and then immediately closes. Office 365 Applications show an exclamation mark against the account name - "Sorry, we can't get to your account right now. To fix this, please sign in again." On the W10-1903 device the majority of UWP apps attempt to open but then immediately close. Office 365 Applications show an exclamation mark against the account name - "Sorry, we can't get to your account right now. To fix this, please sign in again." On the W10-1903 device the following is observed in Event Viewer for the majority of UWP apps, I'll list two examples as it's essentially the same error for each UWP app: Event Viewer – Application Event ID 1000 Faulting application name: Calculator.exe, version: 10.1812.1901.4008, time stamp: 0x5c304989 Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.1, time stamp: 0x59570cf9 Exception code: 0xc000027b Fault offset: 0x0000000000712720 Faulting process ID: 0x298c Faulting application start time: 0x01d51b8175c6ce91 Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1812.10048.0_x64__8wekyb3d8bbwe\Calculator.exe Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll Report ID: 3b2be1d5-7d48-454c-a2f5-3b12bcdc0744 Faulting package full name: Microsoft.WindowsCalculator_10.1812.10048.0_x64__8wekyb3d8bbwe Faulting package-relative application ID: App Event Viewer – Apps - Microsoft-Windows-TWinUI/Operational Event ID 5961 Activation for Microsoft.WindowsCalculator_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040904. Activation phase: COM App activation Event Viewer – Application Event ID 1000 Faulting application name: Microsoft.Photos.exe, version: 2019.18114.19410.0, time stamp: 0x5c5610e0 Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.1, time stamp: 0x59570cf9 Exception code: 0xc000027b Fault offset: 0x0000000000712720 Faulting process ID: 0x2288 Faulting application start time: 0x01d51b819a2b9297 Faulting application path: C:\Program Files\WindowsApps\Microsoft.Windows.Photos_2019.18114.19418.0_x64__8wekyb3d8bbwe\Microsoft.Photos.exe Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll Report ID: 4027c070-d25c-459e-a2d4-2536e12617dc Faulting package full name: Microsoft.Windows.Photos_2019.18114.19418.0_x64__8wekyb3d8bbwe Faulting package-relative application ID: App Event Viewer – Apps - Microsoft-Windows-TWinUI/Operational Event ID 5961 Activation for Microsoft.Windows.Photos_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040904. Activation phase: COM App activation The Weather App: The Weather UWP App fails on both 1803 and 1903 the following is observed in Event Viewer, it essentially appears to be the same error: 1803 Event Viewer – Application Event ID 1000 Faulting application name: Microsoft.Msn.Weather.exe, version: 4.22.1711.21004, time stamp: 0x5a14b3fc Faulting module name: Windows.UI.Xaml.dll, version: 10.0.17134.556, time stamp: 0xd94c4e1e Exception code: 0xc000027b Fault offset: 0x00000000006a6082 Faulting process ID: 0x2bf4 Faulting application start time: 0x01d51b81b6e0246f Faulting application path: C:\Program Files\WindowsApps\Microsoft.BingWeather_4.22.3254.0_x64__8wekyb3d8bbwe\Microsoft.Msn.Weather.exe Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll Report ID: b5d25ea5-5fc0-4c4e-bbbc-f9e8cd3a00b1 Faulting package full name: Microsoft.BingWeather_4.22.3254.0_x64__8wekyb3d8bbwe Faulting package-relative application ID: App Event Viewer – Apps - Microsoft-Windows-TWinUI/Operational Event ID 5961 Activation for Microsoft.BingWeather_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040904. Activation phase: COM App activation 1903 Event Viewer – Application Event ID 1000 Faulting application name: Microsoft.Msn.Weather.exe, version: 4.25.1901.21001, time stamp: 0x5c462b27 Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.1, time stamp: 0x59570cf9 Exception code: 0xc000027b Fault offset: 0x0000000000712720 Faulting process ID: 0x2638 Faulting application start time: 0x01d51b81b4604752 Faulting application path: C:\Program Files\WindowsApps\Microsoft.BingWeather_4.25.20211.0_x64__8wekyb3d8bbwe\Microsoft.Msn.Weather.exe Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll Report ID: 2327e788-0039-4a6b-8488-6e9ef83018e3 Faulting package full name: Microsoft.BingWeather_4.25.20211.0_x64__8wekyb3d8bbwe Faulting package-relative application ID: App Event Viewer – Apps - Microsoft-Windows-TWinUI/Operational Event ID 5961 Activation for Microsoft.BingWeather_8wekyb3d8bbwe!App failed. Error code: Unknown HResult Error code: 0x80040904. Activation phase: COM App activation As I mentioned at the start of this post, I'll update the thread as and when I hear back from Microsoft.

Hi Arthur, Thanks for this, I found others discussing the 'Allow deployment operations in special profiles' GPO during my research last week, I set it to enabled and tried again with a fresh account but it didn't make any discernible difference unfortunately. Cheers, Benzini

Hi all, I'm currently putting together our Windows 10 Enterprise 1903 build and seem to have hit an issue with UWP apps, having spent almost a week working on this issue I thought I'd ask here to see if anyone else has encountered the same issue or has any tried and tested work-arounds from previous builds? Having used the excellent 'OneDriveMapper' powershell script for a number of years I decided to test the latest OneDrive client with 'Files on Demand' enabled, I want OneDrive to sign-in automatically for our users so I've followed documentation to allow our on-premises AD joined devices to perform a Hybrid Azure AD Join, which is a requirement for OneDrive client SSO. The majority of our users hotdesk or use computer labs so we still utilise Ye-Olde Roaming Profiles, we've been evaluating U-EV but there's a number of 'features' that have prevented us from rolling U-EV out, mainly surrounding Outlook client but also the amount of on-going work required managing & maintaining XML templates for U-EV. Anyhow, we're currently observing the following: Log on to a Windows 10 device with a new account that uses a roaming profile OneDrive signs-in automatically (SSO) as expected All UWP apps open and function correctly - eg. Calculator / Maps / Edge / Photos / Skype / Snip & Sketch / Sticky Notes / Voice Recorder / Weather etc ... Office 365 Applications (Word / Excel etc) are signed in (SSO) and function correctly Providing a locally cached copy of the roaming profile remains on the device you can login multiple times to the same device and everything works perfectly, however, if the locally cached profile is removed via GPO or if the user moves to another lab device, things start to fail ... If the locally cached profile has been removed or the user moves to another Windows 10 device OneDrive fails to sign-in - "We can't sync your OneDrive folder" UWP apps mostly fail to open or briefly flash up (attempt to open) and immediately close with the exception of: Maps / Edge / Skype / Sticky Notes Office 365 Applications show an exclamation mark against the account name - "Sorry, we can't get to your account right now. To fix this, please sign in again." I've also tried the above with an account that uses U-EV and get the exact same behaviour, all works fine initially with a fresh account and whilst there's a locally cached profile but if the locally cached profile is removed or the user moves to another device, things start falling apart. I assume this behaviour is due to the fact that UWP apps store information in the 'Local' part of a user profile ... but surely there's a way to make UWP apps work in a domain/hotdesk/lab environment? Any advice, assistance, thoughts gratefully received!

I assume you're hinting at UE-V/ESR, both of which we have considered in the past before deciding they came with substantial admin overhead whilst also not meeting our needs fully, ironically we seem to be one of the few for whom roaming profiles coupled with folder redirection has worked perfectly for the last 18 years. Latest update from Adobe is they're going to look at whether they can redirect (or at least offer the option to redirect) the per-user data to a homedrive/definable location.

Hi all, Has anyone been testing/deploying the new Adobe Creative Cloud Shared Device packages, essentially CC 2019. The .msi packages generated by the Adobe Enterprise site are pretty badly configured to say the least, appearance of unwanted desktop icons and auto launching CC login box to name but a few ... we've solved most of these issues by implementing a GPO to delete icons & registry settings, although it would be nice if we didn't have to do this in the first place. However, the biggest show stopper for us at the moment is the amount of per-user data some of the CC applications create upon initial launch and insist on storing in the roaming section of users profiles, C:\Users\*username*\AppData\Roaming\Adobe\...\... this can be anything up to 1Gb of information just from initially launching the applications, not even using them. This is rather a lot of data to be dragging across the network during logon and will exceed the per-user storage quota we assign to our users, it's the kind of data other vendors redirect to a users home drive to avoid making the roaming profile bulky & slow. I've currently got a ticket open with Adobe who let slip that a number of Schools/FE/HE had been in touch reporting similar issues, which got me wondering, has anyone here experienced the same or similar issues? Any workarounds or fixes would be gratefully received! I'll update this thread as and when I hear from Adobe. Many thanks, Ben

Hello everyone, Our users mailboxes are all hosted in Office 365, we're using Office CTR on-premises and have plenty of bandwidth headroom on our WAN connection. Some of our staff members are reporting issues with the Outlook desktop application whereby the Outlook interface intermittently and briefly turns white, the internal frame of the application remains but the content of the folder list, reading pane and items frames are replaced with solid white backgrounds and the application will often report it's 'Not Responding' ... after 30 seconds or so everything returns to normal. It almost feels like Outlook is trying to communicate with Office 365 and when it's unable to do so it drops the content from the internal frames/windows until it can re-establish communication. The affected individuals are mainly using 'cached' mode although a small number are using 'online' mode. There are a number of posts on-line regarding similar behaviour ranging back to Office 2013 but none of them ever result in a consistent or firm solution. Has anyone else experienced this? If so how did you address the issue, what was the cause? Many thanks, Ben

Has anyone managed to get the CC version of Acrobat DC to install on Windows 10 using GPO / .msi deployment? All other CC software deploys via GPO / .msi aside from Acrobat DC, installing via the setup.exe works but I assume this just calls the .msi? Very odd ...

Hi Steve, Nice scripts, still not exactly what I was looking for, but I may be returning to them if I cant find this elusive AD snap-in ... On the whole our users start in September and graduate three years later, we put them into course and then year of entry OU's ... we disable their accounts after Graduation, wait for 30 days then delete the accounts and data, we find its safe to assume that any student who may have slipped through the student records net will almost always ring our office within 7 days of their account being disabled. We also keep a backup of all graduate data until late September just incase we need to re-create any accounts. I'm really starting to kick myself now, it was a tool I had been after for so long ... Cheers Benzini00

Hi mrtechsystems, Unfortunately not, the software I'm trying to re-discover was 100% free and only performed the single task of removing user data when the user object was deleted in AD ... Thanks for replying though! Benzini00