Office 365

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 B2B

Azure AD B2B has been a lifesaver for me, in giving external clients access to SharePoint Online portals.

There’s a great TechNet article on how it works and how to do it, as well as a great Channel 9 video demoing how it works if you want to dive deeper, but here’s an overview:

Azure AD B2B lets you invite external people via their email address, to use your Azure resources. For me, that’s SharePoint Online, but you can grant access to other Azure resources too.

The process is really simple – you need to fill out a very basic CSV file with each person’s email address and full name, along with a few basic details such as the site you want them to be redirected to, and an ID of the resource you’re granting access to.

The people you’re inviting don’t need their own Azure AD instance which is the best part – if they do, then they just get invited to your instance with the set permissions… but if they don’t, on the fly a pseudo-Azure AD gets set up by Microsoft for the domain their email address is on, and again they’ll get invited to your instance.

This method eliminates the need to do extensive account management, all you have to worry about is inviting them and giving them the permissions they need (which I do via group membership). Password resets they can do themselves, and get a code sent to their email address to use as part of the reset process.

On top of this, there’s no licensing required, which means if you are already covered for SharePoint Online through your Office 365 sub, this is a very cheap way to make customer facing portals to share information with, that’s locked down and hosted in the HA environment of Office 365.

I was surprised at how simple it was to invite, and even from the end user’s perspective of receiving the invitation – the process is very easy.

At the time of writing, Azure AD B2B is in public preview and may have a few bugs.

Identifying and Counting Office 365 Cloud vs On Premises Users

How do you easily identify Cloud and On Premises 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-premises 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-premises 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-premises 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

Adding Multiple Cloud Users to an Azure/Office 365 Security Group

This one had me stumped for a while – how do you get a bunch of users in Office 365/Azure and then add them to a security group? This was met with the relevant tweets of frustration, such as:

After mucking around for a while, and getting Microsoft MVP David O’Brien to listen to my woes, I ended up working out a solution.

Part of my confusion was around this TechNet article for the command Add-MsolGroupMember which at the time of writing, I’m convinced is wrong. The example they give is to get a user and a group, then add the user to the group…. except, they’re used the get-msolgroup command to do so.

When I tried to switch this over to a user lookup with multiple user results, I received this error:

Add-MsolGroupMember : Cannot convert ‘System.Object[]’ to the type ‘System.Guid’ required by parameter
‘GroupObjectId’. Specified method is not supported.

Long story short, most Office 365 user/group commands I’ve come across don’t support multiple inputs, so you can’t feed a list of results through – it’s one at a time. Also, groups and users only seem to support using the Object ID of each object, so you can’t easily use names, email addresses etc. This means you’ll need to run commands to get those Object IDs based on the information you know.

To get around this, you’ll need to use the ‘foreach’ command – then it’ll go through each of your results one by one. I’ll go through this step by step:

1. Get your group:

$group = get-msolgroup | where {$_.Displayname -eq “All Office365 Users”}

Pretty self explanatory, we’re making the variable $group equal the object of the group name specified.

To check what users came back, you can just type $group

2. Get your users:

$users = get-msoluser | select userprincipalname,objectid | where {$_.userprincipalname -like “*domain.com*”}

Similar to the above, we’re making the variable $users all the users we want to add to the group, based on the User Principal Name containing “domain.com”. We’re also making sure we grab the object id of each of those users.

3. Adding the users to the group

$users | foreach {add-msolgroupmember -groupobjectid $group.objectid -groupmembertype “user” -GroupMemberObjectId $_.objectid}

This is showing the users we set earlier, then for each record, running the command ‘add-msolgroupmember’ based on the group we discovered in step 1, and the users from step2. Notice we call the Object ID for each of these objects, as the commands only support it as an identifier.

4. Check what users are in the group

get-msolgroupmember -groupobjectid $group.objectid

This will show you all the members of the group you’ve been working on.

With the above, you can use pretty much any search criteria for step 2, and add those users to your group.

Note that all the above is only for ‘In Cloud’ users, if they were on premesis and being synced to Azure AD/Office365, you’d run different commands against your on premise Active Directory environment.

Connect to all Office 365 services via PowerShell

I found this great TechNet article and wanted to share:

Connect to all Office 365 services in a single Windows PowerShell window

It’s a greatly described article about how to connect to each Office 365 service – MSOL itself, Exchange Online, Skype For Business, SharePoint Online and the Compliance Center.

If you go through the article, you can set up a script to prompt you once for Office 365 administrator credentials, and connect to each service for a one stop shop on managing your Office 365 environment from PowerShell.

One catch (which is mentioned in the article) is that you’ll need to run PowerShell in Administrator mode, or you won’t be able to import modules. You’ll see an error like:

The specified module 'Microsoft.Online.SharePoint.Online.PowerShell' was not loaded because no valid module file was found in any directory.

If you aren’t sure if you’re in Administrator or User mode, the default path prompted in the PowerShell window will be “PS C:\users\username>” for User mode, and “PS C:\Windows\system32>” for Administrator mode (along with the word “Administrator” in the PowerShell window title.

I’m only new to Office 365, but I’ve found the GUI via the web for user management rather basic – I can’t do simple tasks such as search for users on a specific domain, then add them to a group. PowerShell is absolutely necessary if you want to manage Office 365.