Search the Community

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'm configuring an automated Visual Studio 2017 Community Ed installation for Visual Basic desktop application development. Works fine, except I only get UWP ("Universal / Modern application") as a option when creating new projects. Which extra workflows do I need to install to enable desktop application development for systems other than Windows 10? Alternatively, has anyone had any issues with just installing the whole thing? Only installed workflows are currently "Microsoft.VisualStudio.Workload.NativeDesktop" and "Microsoft.VisualStudio.Workload.Universal Current respone.json, in case anyone else is looking to deploy. Build using guidance from Microsoft Docs {"installChannelUri":".\\ChannelManifest.json","channelUri":"https://aka.ms/vs/15/release/channel","installCatalogUri":".\\Catalog.json","channelId":"VisualStudio.15.Release","productId":"Microsoft.VisualStudio.Product.Community","installPath": "C:\\Program Files\\VisualStudio 2017 Community Edition","quiet": false,"passive": false,"includeRecommended": true,"norestart": true,"addProductLang": "en-US","add": ["Microsoft.VisualStudio.Workload.NativeDesktop","Microsoft.VisualStudio.Workload.Universal"]} Edit: Solution was to install ".Net Desktop Development" (Microsoft.VisualStudio.Workload.ManagedDesktop)