“Microsoft accounts” vs. Microsoft’s “organizational accounts”

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

If you’re using Microsoft’s online services, you might reasonably expect to authenticate against some form of directory service.  And, if you have your own directory service (like Active Directory), you might reasonably expect to be able to synchronise it with your cloud identity to provide a holistic view to end users. Unfortunately, whilst both of these things are possible, the end result can be really confusing and I’ve just had to explain it for one of my customers.

You see, a “Microsoft account” is not what you use to log on to Office 365 (or Intune, Azure, etc.) – for that you need an “Organizational account” (which is held in Microsoft Azure Active Directory) – although you might have logged on to your Windows PC, phone or tablet with a Microsoft account.

Still with me? No! Well, let me quote from an MSDN article:

“Q. What is the difference between “Organizational account” and “Microsoft account”?
Organizational account is an account created by an organization’s administrator to enable a member of the organization access to all Microsoft cloud services such as Microsoft Azure, Windows Intune or Office 365. An Organizational account can take the form of a user’s organizational email address, such as username@orgname.com, when an organization federates or synchronizes its Active Directory accounts with Azure Active Directory. […]

Microsoft account, created by user for personal use, is the new name for what used to be called “Windows Live ID”. The Microsoft account is the combination of an email address and a password that a user uses to sign in to all consumer-oriented Microsoft products and cloud services such as Outlook (Hotmail), Messenger, OneDrive, MSN, Windows Phone or Xbox LIVE. If a user uses an email address and password to sign in to these or other services, then the user already has a Microsoft account—but the user can also sign up for a new one at any time.”

Right. Hopefully that’s a bit clearer? Unfortunately the whole thing gets really messy when you have multiple browser tabs connected to different services and I often find I have different browsers (or InPrivate/Incognito browser sessions) running in parallel to access services.  One approach, although probably not recommended, is to manually synchronise the passwords between a Microsoft account and an Organizational account that have the same email address to give the illusion of single sign-on.

Maybe one day all of the consumer services will move to Azure Active Directory and we can just have a single identity. Probably not though… that’s what Microsoft Passport (Windows Live ID’s predecessor) was trying to do back in 2001 and it felt a bit “big brother” to some people (although today we seem quite happy to have Google and Facebook act as identity providers for multiple services).

Post Script

Since I wrote this post, “organizational accounts” have become known as “work or school accounts”, which I guess makes things a little clearer, even if the phase is a touch unwieldy!

Microsoft #TechDays Online 2015

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last week, was Microsoft UK’s TechDays Online conference, held over three days with thousands of virtual attendees watching/listening to sessions on a variety of topics, starting off in the IT Pro arena with a keynote on Windows 10 from Journalist and Author Mary Jo Foley (@MaryJoFoley), Windows Server, on to Intune, Office 365, progressing to a variety of Azure topics, containerisation and DevOps with a keynote from Microsoft Distinguished Engineer Jeffrey Snover (@JSnover) and eventually into full developer mode with a keynote from Scott Hanselman (@SHanselman).

This is the fourth year that Microsoft has run these events and I was fortunate to be invited to watch the sessions being recorded.  I attended the first afternoon/evening and the second day – driving my Twitter followers mad with a Microsoft overload. For those who missed it, here’s a recap (unfortunately I couldn’t commit the time to cover the developer day):

(I later retweeted this:)

And we continue…

Actually, he didn’t – I later published this correction:

And back to my stream of Twitter consciousness:

Sadly, I missed Mary Jo Foley’s keynote (although I did manage to get over to Microsoft’s London offices on the second evening for a Live recording of the Windows Weekly podcast and caught up with Mary Jo after the event).

Sessions were recorded and I’ll update this post with video links when I have them.

Choosing an Office 365 identity model (when to use ADFS)

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

At the time of writing, Microsoft Office 365 has the ability to work with three identity models:

  • Cloud identity (stored in Microsoft Azure Active Directory).
  • Synchronised identity (a copy of the objects from an on-premises Active Directory is made in Microsoft Azure AD), optionally with synchronised password hashes.  This is also known as same sign on (not single sign on as there are still two separate objects, albeit two objects that are kept synchronised).
  • Federated identity, using a federation service (such as Active Directory Federation Services, but others are supported) to authenticate users in an on-premises directory following which authorisation can be granted to Office 365 resources. This is also known as single sign on.  In this instance, directory synchronisation is still used to populate the Azure AD with user objects, although authentication happens on-premises.

Whilst the majority of small businesses will be fine with cloud identities, many of my conversations with enterprise customers start off in the directory synchronisation space. Generally, synchronisation is performed using the Office 365 DirSync appliance (a customised version of Forefront Identity Manager) although, more recently a new tool (Azure AD Sync) has been released that will eventually replace DirSync.  At the time of writing the main difference is that Azure AD Sync supports multiple forests (DirSync is a single forest solution) but it doesn’t support password synchronisation (still a major advantage for DirSync).

In general, the approach I recommend is to choose the simplest model for the organisation’s needs. The cloud identity model can work well when there is no on-premises directory service or there is no requirement to integrate; synchronised identity is the most commonly used (assuming there is an existing Active Directory) but sometimes federation is required:

  1. If there is an existing ADFS infrastructure.
  2. If a third party federated ID provider is in use.
  3. If Forefront Identity Manager 2010 is in use (which does not support password synchronisation).
  4. If there are multiple on-premises Active Directory forests (although Azure AD sync may negate this requirement).
  5. If smart cards or other third-party multi-factor authentication solutions are in use (Azure AD does have an MFA capability, although there are some restrictions on its use).
  6. If custom hybrid apps or hybrid search are in use (SharePoint).
  7. If a hybrid Lync solution is in use (i.e. placing users with enterprise voice capabilities on premises and those that don’t need voice in Lync Online, sharing the same SIP namespace).
  8. For self-service password reset via a web service (only administrators have self-service password reset in Office 365).
  9. If there is a requirement to audit logins and/or immediately disable accounts.
  10. If there is a requirement for single sign-on (i.e. accessing Office 365 workloads with the same user credentials as on-premises).
  11. If there is a requirement to restrict client logins by time or location.
  12. If the organisational security policy prevents the synchronisation of password hashes to Azure AD.

On a related topic, the Microsoft Online Services Sign-in Assistant (MOSA) for IT Professionals only exists to simplify the user experience (handling tokens, etc.) and is generally not required with modern versions of Office. Administrators using PowerShell may still need it though.

Finally, if ADFS is down, there is no way for users to authenticate. For that reason, federated infrastructure needs to be highly available (e.g. multiple ADFS proxies and multiple ADFS servers).  One method that’s starting to be commonly recommended is an “ADFS safety net”, using DirSync as a fall back (it’s possible to move between identity models on demand) but obviously that’s only an option if your organisation’s security policy allows the synchronisation of identities (including password hashes to minimise the impact on end users).

For reference, the PowerShell commands are:

Convert-Msol-DomainToStandard -DomainName domainname.tld -SkipUserConversion $true
Convert-Msol-DomainToFederated -DomainName domainname.tld

Set-Msol-DomainAuthentication -Authentication Managed -DomainName domainname.tld
Convert-Msol-DomainToFederated -DomainName domainname.tld

Credit is due to Michel de Rooij (@mderooij) for the ADFS safety net tip.

My new Office 365 Resource Centre

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been doing a fair amount of work with Office 365 in recent months (including passing certification exams) and, along the way, I’ve found a lot of snippets of useful information. Normally I’d write a blog post but I expect to be constantly adding to the information so I thought I’d create a different solution this time.

So, I’ve started to create what’s currently known as Mark’s Office 365 Resource Centre. It’s work in progress – and I’m sure the structure will change as it grows over time – but at least I’ve found something to do with the public website on my Office 365 subscription!

Microsoft course review: 10968B (Designing for Office 365 Infrastructure)

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve spent the last three days on a Microsoft Official Curriculum training course at QA – Course 10968B: Designing for Office 365 Infrastructure. Like many Microsoft courses, this is badly named (it won’t teach you how to design for Office 365) but I really did find it useful because it focuses very heavily on Microsoft’s FastTrack deployment methodology for Office 365.  Stepping through each of the stages of pilot (although it’s questionable whether enterprises will do this), deploy and enhance, the course reminds us of the key points to consider at each stage with labs to work through with a fictitious company (for once, it’s not Contoso).  Then, the final module is a full case study (using Trey Research of course) where the class divides into groups and works with the instructor (as a customer) to walk through a series of meetings to understand the environment and make the appropriate decisions for use of the Office 365 services.

I found it really beneficial – particularly the final exercise – as I’m doing this with customers all the time and it’s good to compare the approach I take with the Microsoft recommendations.  I was fortunate as well that we had a very knowledgeable instructor, Dan Lewis, and that led to some really good classroom conversations (in contrast to an Exchange course I attended at the same venue last year, where the instructor was limited in her knowledge) – and the range of roles in the room (midsize company infrastructure manager; large enterprise employees; specialist service provider; systems integrator) also added to the depth of discussion.

The one negative – and it’s a huge one – was the courseware.  Microsoft has moved from printed materials to online content and I can understand the reasons (both financial and environmental) but the system used is awful.  Microsoft Learning have partnered with Skillpipe, who have a content platform using a proprietary document format (presumably for reasons of digital rights management – although why they can’t use Microsoft’s own DRM is beyond me) and the content is only available in browser, or in a reader app for Windows (Vista/7 or 8/RT). No mobile devices – not even Windows Phone!  Added to which I find it really difficult to absorb information on screen (e.g. reading a scenario) and it really damages the learning experience.

Incidentally, if you want to learn about the detail of Office 365, this course is not for you – there’s a 5 day hands on course (Course 20346B: Managing Office 365 Identities and Services or you can access the same content, minus the hands-on elements, in the Microsoft Virtual Academy). And, if you really think that’s all a bit too much fuss and you would like to engage a Microsoft Partner instead… then you could always contact me at work!

OneDrive for Business: lots of cloud storage; terrible sync client

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been a Dropbox user for years but with Microsoft’s upgrade of OneDrive for Business (formerly Skydrive Pro) to include 1TB of storage for every Office 365 user, I decided to move the majority of my files to that platform.  I could pay for additional Dropbox storage but, frankly, why do I need to, with that much storage included in my Office 365 E1 subscription?

However, after a couple of days trying to force a synchronisation of legacy content into OneDrive for Business (noting the various restrictions), I have drawn the following conclusion:

The One Drive for Business sync engine is “pants” (definition 3 in the OED).

It’s straightforward enough to define folders for syncing into SharePoint Online (which is where OneDrive for Business stores data), and most of my content synced OK but I had one folder of correspondence, going back to my early days of using a PC (some WordStar and WordPerfect files, as well as some very early Word formats in there – right through to current day documents) that was causing difficulties.

Unfortunately, whilst the OneDrive for Business client is able to sync folders in parallel, it seems to work through a folder in serial. If it comes up with a problem, it doesn’t seem to skip it and move on – at least not in the way that might be expected. It might flag an issue, but there’s no “skip file” option. And it doesn’t seem to have a method for forcing a sync either. Or for telling me which file it’s currently attempting to work with.  Here’s what I found…

Uploading files directly to OneDrive will change the modified date (perhaps to be expected):

Opening a “stuck file” in Word will present a sign-in error:

Even if you are already signed in:

and verified with File, Account

No good attempting to sign out (and in again) either:

(I’m logged into my Windows 8.1 PC using a Microsoft account, although I can switch to the organisation account that uses the same credentials for Office 365 access).

One thing I found that would sometimes kick-start proceedings was (in Word) removing the Connected Service for OneDrive – markwilson.it (and then adding it again, which forces a re-authentication):

Sometimes, I found that wasn’t necessary – just by ignoring the “credentials needed” error it might go away after a while!

I even resorted to opening each “stuck file” and closing it again, making sure I didn’t actually change it (clicking the Sign In button will update the document). This seemed to unblock things for a while until, eventually, I found myself in a situation where Word wouldn’t open any of the content waiting to sync. Some of the errors suggested it was trying to download the cloud copy rather than the local one whilst other times it failed silently.

In fairness, OneDrive for Business does have an option to repair the synced folders but that downloads everything from SharePoint again… and as half of it hadn’t got up there yet that wasn’t going to help much!

I re-installed Office 2013 and was just about to do the same with OneDrive for Business (which turns out to be based on Groove) but, instead, I decided to simply create a new folder and paste the files into that – effectively a second copy of the data to start the sync again from fresh.

After all the fighting with the first copy, the second copy synced in a few minutes (well, it got stuck on a few files but I deleted them, then pasted them in again, after which they synced).  It seems that, fundamentally, the OneDrive for Business sync engine is more than a little bit flaky (which doesn’t leave me feeling good about my data).  Thankfully, Microsoft is reported as acknowledging that the sync limits are “well understood” – and I hope that doesn’t just include the limits on item counts and file naming imposed by the SharePoint back-end.

Isn’t this is all just a bit too much effort for what Dropbox (and others) have made so simple?

Some tools in Outlook 2013 for diagnosing Exchange connectivity issues

Posted on By Mark Wilson
This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve just been looking at some of the diagnostic information that’s available for Outlook connections to Exchange (including Exchange Online in Office 365) and one “hidden” feature (actually, it’s not hidden but it’s not very well known) is the ability to Ctrl+right click on the Outlook icon in Windows’ notification area to bring up two extra menu options:

The first of these is handy for bringing up information about the various client-server connections open between Outlook and Exchange (for example the connection protocols being used, port numbers, session types, etc.):

The second allows testing/diagnosis of AutoDiscovery functionality – again, providing a host of information to track down issues:

Combined with the Microsoft Remote Connectivity Analyzer, these are a few tools to help IT admins track down the cause of connection issues.

Administering Office 365 using PowerShell: updated information on the required components

Posted on By Mark Wilson
This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve written before about administering Office 365 from PowerShell but the process has changed slightly over the years.  There are various articles out there on the web with methods and links but the key information (as at August 2014) is in a TechNet article titled Manage Azure AD using Windows PowerShell.  Yes, that’s right – Azure AD – because Windows Azure Active Directory is the authentication service used by Microsoft Online Services such as the Office 365 services.

On my Windows 8.1 computer I already had the necessary .NET framework and PowerShell pre-requisites but I did need to download and install two more components before Get-Command -Module msonline would do anything for me:

  1. The Microsoft Online Services Sign-In Assistant for IT Professionals RTW (the version I used was 7.250.4556.0, published on 17 February 2014).
  2. The Windows Azure AD Module for Windows PowerShell* (which depends on the Microsoft Online Service Sign-In Assistant), which doesn’t come up in a search on the Microsoft Downloads Center but is linked from the TechNet article I mentioned above (32-bit and 64-bit versions).

With these components installed, I could authenticate against the service using my normal credentials with Import-Module MSOnline and Connect-MsolService and run administration cmdlets from within PowerShell.  Note that in order to run Exchange cmdlets, you’ll need a remote PowerShell session to Exchange (check out Greg Shields’ TechNet magazine article Manage Office 365 with Windows PowerShell for more details). There are also additional modules for managing Lync Online and SharePoint Online.

 

* The Windows Azure Active Directory Module for Windows PowerShell cmdlets were previously known as the Microsoft Online Services Module for Windows PowerShell cmdlets.

Confusion over accounts used to access Microsoft’s online services

Posted on By Mark Wilson
This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I recently bought a new computer, for family use (the Lenovo Flex 15 that I was whinging about the other week finally turned up). As it’s a new PC, it runs Windows 8 (since upgraded to 8.1) and I log in with my “Microsoft account”. All good so far.

I set up local accounts for the kids, with parental controls (if you don’t use Windows Family Safety, then I recommend you do! No need for meddling government firewalls at ISP level – all of the major operating systems have parental controls built in – we just need to be taught to use them…), then I decided that my wife also needed a “Microsoft account” so she could be registered as a parent to view the reports and over-ride settings as required.

Because my wife has an Office 365 mailbox, I thought she had a “Microsoft account” and I tried to use her Office 365 credentials. Nope… authentication error. It was only some time later (after quite a bit of frustration) that I realised that the “Organization account” used to access a Microsoft service like Office 365 is not the same as a “Microsoft account”. Mine had only worked because I have two accounts with the same username and password (naughty…) but they are actually two entirely separate identities. As far as I can make out, “organization accounts” use the Windows Azure Active Directory service whilst “Microsoft accounts” have their heritage in Microsoft Passport/Windows Live ID.

Tweeting my frustrations I heard back from a number of online contacts – including journalists and MVPs – and it seems to be widely accepted that Microsoft’s online authentication is a mess.

As Jamie Thomson (@JamieT) commented to Alex Simons (@Alex_A_Simons – the Programme Director for Windows Azure Active Directory), if only every “organization account” could have a corresponding “Microsoft account” auto-provisioned, life would be a lot, lot simpler.

Remote PowerShell to manage Exchange, even without the Exchange Management Shell installed

Posted on By Mark Wilson
This content is 11 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Following on from yesterday’s Exchange Admin Center/Outlook Web App tips, I thought I’d share another gem that came from Microsoft Exchange Premier Field Engineer and PowerShell author Mike Pieffer (@mike_pfeiffer) in the Microsoft Virtual Academy Core Solutions of Microsoft Exchange Server 2013 Jump Start course.

Sometimes, you’ll need to perform an operation on an Exchange Server and you won’t have the Exchange Management Shell installed.  You may be able to carry out the operation graphically using the Exchange Admin Center but, more likely, you’ll need to invoke a remote PowerShell session.

The magic commands (which need PowerShell v2 or later) use implicit remoting via the IIS PowerShell virtual directory (proxied via an Exchange server with the CAS role installed):

$session = New-PSSession -ConfigurationName microsoft.exchange -ConnectionUri http://servername/powershell
Import-PSSession $session

After running these commands, you should be able to run Microsoft Exchange cmdlets, as long as you have the appropriate permissions assigned via Exchange’s Role Based Access Control mechanism. I’ve used the same approach previously to connect to Exchange Online (Office 365) using remote PowerShell.

A couple of additional points to note: because you’re running a remote PowerShell session, you’ll also need the script execution policy to allow RemoteSigned scripts; also, don’t forget to tear down the session when you’re done, using Remove-PSSession $session.