Azure AD

Intune – Couldn’t Enroll your Device

We started having issues with new enrolments to Intune. Nothing had changed that we were aware of, but registering a new device brought up the error “Couldn’t enroll your device. You can try again or send the error information to your IT admin in an email.” iOS or Android, didn’t matter:

screenshot_20160922-180510Intune Enrollment Error

After testing multiple accounts and multiple devices, I logged a call with Office 365 support, and eventually we worked out that for my account, I didn’t have a license applied. Intune sits under our Enterprise Mobility Suite package:

licenseIntune License is “Off”?

After checking other users, I found that everyone was in this ‘Off’ state. Weird, because we hadn’t done this, and Intune licensing was being managed by a group via Azure AD as per these instructions. That configuration was still in place too when I checked. I decided to do the logical thing and ‘turn it off and back on again’ – so I disabled the assignment on that page, then re-enabled the same group with the Intune license.

After then going back to the Office 365 User search, I found that all the users had now changed to ‘on’ again. The only recent event in the last few weeks was a renewal of our licenses, so I wonder if something happened in the back end as a part of that?

Anyway, if you see the ‘Couldn’t enroll your device’ message when using the Intune Company Portal app, make sure the user has their Intune license enabled!

Important Azure and Office 365 URLs for Admins

I keep forgetting some of the main URLs I need for Microsoft’s online cloud based services. Instead of going direct to where I want, I log into one point I know and follow the bouncing ball to get to my destination – hardly efficient.

Instead, here’s my list of important Azure and Office 365 URLs to get where you want. The ones that require your domain as part of the URL aren’t hotlinks.

Office 365
Office 365 Admin Portal https://portal.office.com/adminportal/home?switchtomodern=true#
Office 365 Admin Portal (old) https://portal.office.com/Admin/Default.aspx?switchtoclassic=true#
Office 365 Portal with specific internal domain https://login.microsoftonline.com/?whr=yourdomain.com (modify to your own domain on the end)
Office 365 Apps https://portal.office.com/myapps

Azure
Azure AD and Old Portal https://manage.windowsazure.com
Azure AD and Old Portal to a specific domain https://manage.windowsazure.com/yourdomain.com (modify to your own domain on the end)
Azure New Portal https://portal.azure.com/

Intune
Intune Admin Portal https://manage.microsoft.com/MicrosoftIntune/

Skype For Business Online
Skype For Business Admin Portal https://adminau1.online.lync.com/lscp/ (possibly Australia only?)

Exchange Online
Exchange Admin Center https://outlook.office365.com/ecp/

Apps
Power BI https://app.powerbi.com
Exchange Online Mailbox https://outlook.office365.com/
Yammer https://www.yammer.com/office365
SharePoint Online https://yourdomain.sharepoint.com/_layouts/15/sharepoint.aspx
Planner https://tasks.office.com
Office Online (Word, Excel etc) https://office.live.com
Sway https://www.sway.com/
Security and Compliance https://protection.office.com
Office Store https://portal.office.com/store

 

Microsoft have a list of all Office 365 URLs and IPs too, but that’s for you to configure your firewall preemptively rather than an Office 365/Azure Admin.

If you have any adds or changes, please let me know!

 

Update 7th September 2016

Microsoft have put up a giant list of links to all the Azure bits and pieces, check it out!

Azure AD Connect Health with AD DS

Azure AD Connect Health with AD DS is now in preview!

You’ll need Azure AD Premium for this, but it’s a little agent that gets installed on each of your domain controllers and provides health and alerting via Azure AD Connect Health.

The service is a light health and monitoring solution which reports back on some basics such as these:

azure health 3

Also, it will show any replication issues and other DC related problems for you to re-mediate. You can also configure email alerts, so you know when a problem is detected, rather than relying on checking the health page to notice something.

The setup of Azure AD Connect Health with AD DS is incredibly easy – download and install the agent (check you meet the prerequisites first!), use credentials of an Azure AD global administrator (set up a service account for this), and you’re done. If you install it on a server that doesn’t have the required Windows Server roles, you’ll get an error such as ” Microsoft.Identity.Health.Common.RoleNotFoundException: No role was registered.

The two other currently Health services are for ADFS and Azure AD Connect, so check those out too if you haven’t already.

One issue I had after installing was that I couldn’t see the box for Active Directory Domain Services in the Azure portal, it was just blank:


Pasted image at 2016_07_21 12_22 PM

After trying to work out why for a while, @kengoodwin pointed out that I should try resetting the view. This is done by clicking one of the ‘Add tiles’ options, then at the top of the screen choosing hte ‘Restore default’ option.

Doing this resulted in my tiles showing as they should – I’d never made adjustments to my tiles, but had previously gone into edit mode and saved the zero changes I did, which I believe stopped the portal from adding in the new tiles once the new health service was detected. This is how it should look:

ad health 2

Much better!

If you have Azure AD premium, then check out this free extra!

Identifying and Counting Office 365 Cloud vs On Premise Users

How do you easily identify Cloud and On Premise users in your Office 365/Azure AD instance? With PowerShell of course!

Prerequisite – Windows Azure Active Directory Module

Using the ‘get-msoluser -all’ command, you can find all your users in Office 365/Azure AD. Getting the results of which users are cloud only based, or synced via an on-premise LDAP such as Active Directory may not be easy at first glance.

If you expand out all the details possible from a user, the fields are as follows:

get-msol1

None of these are obvious to indicate where the account is primarily located.

After a quick comparison of an on-premise account and a cloud account, I noticed the ‘ImmutableId’ was blank for the cloud users. I found a great blog post about what the value was for here, which proved my guess – the value corresponds to the ‘objectGUID’ of the account, which cloud-only accounts don’t use.

Based on that, the rest is simple. Here’s some example commands:

get-msoluser -all | where immutableid -eq $null
Get a list of all cloud only accounts

get-msoluser -all | where immutableid -eq $null |fl
Get all cloud only accounts with all values

get-msoluser -all | where immutableid -ne $null
Get all synced on-premise accounts (e.g. DirSync, Azure AD Connect, ADFS)

get-msoluser -all | where immutableid -eq $null |measure
Show a count of how many cloud only accounts

get-msoluser -all | where immutableid -eq $null | export-csv cloudusers.csv
Export the list of cloud only accounts to a csv file