Organizing your OneDrive for Business

We all agree that folders are bad, right? They only make sense at a certain point in time and only mean something to the person who created them. Everyone hates the folders in SharePoint which someone else created, but I find the majority of people still organize their personal OneDrive for Business files within folders.

The problem with this is that OneDrive for Business screams and begs for you to share those files with others, so users create folders as a mechanism to define who has access to sets of data. Folder names like the built-in "Shared with Everyone" or "Shared with Team X" become the ACLs which makes sense for a specific project, but that concept quickly detoriates when project members change or someone else needs access to a subset of content within that folder.

I was guilty of the same crime for a long time, but have recently adopted a new technique I think works really well. It goes like this:

  • Store all your files in a completely flat structure within OneDrive for Business, and set permissions only at the file level. No folders allowed. Sort the view by Modified Date for an extra boost because this way everything you're actually working on is front and center, similar to a "Recent Documents" view.

  • If a group of files lend themselves to being shared together, put them on SharePoint or in an Office 365 Group. Your personal OneDrive for Business isn't the best fit for a set of documents which are related. You should set up a document library, team site, or Office 365 Group to move that effort forward. Sync that location to keep a local copy handy.

  • Create a single folder called Archive. Similar to mail archive concepts the only thing that goes in here are files you haven't accessed in a really long time and need to keep around for reference.

Windows 10 Enterprise & Credential Manager

Updated 4/26/2016: Turns out this is not specific to Windows Enterprise or Professional, but actually related to Azure AD Join and Windows Hello. If your machine is joined to Azure AD during the OOBE installation step and you sign in with a Hello method (face, fingerprint, PIN) then Credential Manager is busted. But if you bypass Hello (cover your face!) and use a password then Credential Manager is "unlocked" and works exactly as expected. From what I can tell this has to do with how Microsoft Passport containers work and because Windows Hello will only unlock a single container. If your machine is joined to Azure AD the Enterprise Container is what Hello authentication unlocks, but Credential Manager only functions when the default (non-Enterprise) container is unlocked.

Credential Manager has been a part of Windows for a long time now and I've noticed it seems to have stopped behaving as expected in builds of Windows 10 Enterprise Edition. To be more specific, defining a saved Windows credential in Credential Manager and then adding the same address to the Local Intranet Zone of Internet Explorer used to result in a SSO experience for the user. The machine would pass the saved credentials automatically without the user seeing any kind of authentication prompt.

This was a very handy trick for machines which weren't joined to a domain and needed to authenticate to various sites or applications without requiring the user to type their password over and over throughout the day. You could save a Windows credential for * and add that same wildcard definition to the Local Intranet Zone to cut down on practicing your password-typing skills.

What I've noticed is that while the Professional Edition continues to work like prior versions of Windows the Enterprise Edition will always present the authentication prompt, even with the exact same configuration.

If you try to track down potential differences you'll quickly run across Credential Guard, a feature unique to Enterprise Edition which Microsoft describes as this:

Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets.

Sounds great. This feature doesn't run by default, but after a couple of steps via GPO I was able to enable Credential Guard and validate it was running on my Surface Pro 4. But after removing and adding the saved credentials to Credential Manager I was in the same spot with being constantly prompted.

Reading a little further down the Technet page about Credential Guard you'll also find this innocuous-sounding statement:

Starting with Windows 10, version 1511, domain credentials that are stored with Credential Manager are protected with Credential Guard. Credential Manager allows you to store credentials, such as user names and passwords that you use to log on to websites or other computers on a network. The following considerations apply to the Credential Guard protections for Credential Manager:

  • Applications that extract derived domain credentials from Credential Manager will no longer be able to use those credentials.

The emphasis there is mine, but I think that last statement is key. I've been unable to find any documentation which clearly states this means Windows credentials saved in Credential Manager won't work, but I think they fall into the derived domain credentials category.

What doesn't add up is that this feature is supposed to be unique to Credential Guard, but it seems to prevent Credential Manager from working with Windows credentials even when not enabled.

I suppose you could make the argument that only corporate-owned devices would run Enterprise Edition and that any corporate-owned device shouldn't be storing saved credentials, but I'd still prefer to see this as a configurable setting even if the default behavior is to block the usage.

Clearing up the clear and simple guidance about Configuration Manager and Intune

Brad Anderson of Microsoft recently highlighted a new post from the Intune team full of ridiculous flow charts which supposedy deliver "clear and simple guidance" about when to use System Center Configuration Manager vs. Intune for device management.

Hopefully the flow charts didn't require much labor because they are completely unnecessary. Here's the extracted clear and simple guidance about which tool is most appropriate for each scenario:

  • Configuration Manager: Corporate-owned device which is not mobile, already on the domain, or requires fine-grained settings control via GPO.
  • Azure Active Directory Join + Intune MDM: Corporate-owned device which is mobile, not on the domain today, and does not require fine-grained settings control via GPO.
  • Azure Active Directory "Add work account" + Intune MDM: Personal device not owned by the company.