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
Office 365 Admin Portal (old)
Office 365 Portal with specific internal domain (modify to your own domain on the end)
Office 365 Apps

Azure AD and Old Portal
Azure AD and Old Portal to a specific domain (modify to your own domain on the end)
Azure New Portal

Intune Admin Portal

Skype For Business Online
Skype For Business Admin Portal (possibly Australia only?)

Exchange Online
Exchange Admin Center

Power BI
Exchange Online Mailbox
SharePoint Online
Office Online (Word, Excel etc)
Security and Compliance
Office 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.

Fix Wrong Domain for Users Azure Active Directory

I ran into a problem where a user couldn’t sign into Intune, which uses Azure Active Directory to authenticate users.

After checking the user in question on the Azure Active Directory portal, I noticed the domain was wrong:


The user was being synced from On Premise Active Directory, so I had a look via Users and Computers to see what was going on. The user’s User Principal Name domain field was set differently to other users – instead of the proper, it was set to mydomain.local – another valid internal domain to Active Directory, but not one that Azure Active Directory knew about:


The unknown domain caused Azure Active Directory to disregard it, and instead use it’s default tennancy domain of I thought just changing the dropdown menu to instead of mydomain.local would fix it, but a forced Azure Active Directory Sync sync reported the change was successfully synced, but didn’t actually change the value.

I’m going to guess this is by design, as you don’t usually want logins changing. There is an easy way to change the via PowerShell instead.

Once you’ve run the standard ‘Connect-MsolLService‘ cmdlet, you can use ‘Set-MsolUserPrincipalName‘ to change the user. The full command is:

Set-MSolUserPrincipalName -userprincipalname “[email protected]” -NewUserPrincipalName “[email protected]

Pretty simple, and the change is immediate.

I then realised there may be other users with the same problem, so dediced to use the Active Directory PowerShell Module with this command:

get-aduser -filter * | where {$_.userprincipalname -like “*local*” -and $_.enabled -eq “true”} | select name

This showed all the users who had ‘local’ in their UPN. As there were only a few, I changed them all one by one with the first command above.

The same check can be run against Azure Active Directory users with this command:

get-msoluser -all | where userprincipalname -like “*local*”


Azure AD Connect

Today a new version of Azure AD Connect was released – v1.1.105.0 (even though the site says 2/16/2016, but wasn’t there yesterday!)

The download link is here:

If you want a reminder on what Azure AD Connect is, Microsoft have a great article here. It replaced Dirsync and AADSync

It’s worth the upgrade, full release notes are here but the big change in my opinion is:

New preview features:

  • The new default sync cycle interval is 30 minutes. Used to be 3 hours for all earlier releases. Adds support to change the scheduler behavior.

30 minutes is much nicer to wait for a change (this doesn’t include passwords) than 3 hours.

Note that this used to be controlled from a scheduled task in DirSync and AADSync, but now runs as the Microsoft Azure AD Sync service. If you want to check that your sync has now changed to 30 minutes, run the PowerShell command  “Get-ADSyncScheduler” and you should see the values of AllowedSyncCycleInterval and CurrentlyEffectivSyncCycleInterval both as 30 minutes:


If you’ve already got the connector installed, it will just install over the top using your existing settings. It just requires re-entry of your Azure AD credentials for syncing, and took me about two minutes to run.


Update: 1st March 2016

Due to a bug with the time, version has been released. Please use that instead of

Azure AD Connect – Password Sync Times

Azure AD Connect is a Microsoft utility that will sync your Active Directory records to Azure AD/Office 365. An introduction to this is available here.

One of the benefits of Azure AD is being able to use it as your point of authentication for users over the internet, without having to poke holes in your on-premises firewall. I was considering this for a 3rd party solution – but I had a concern.

How Do Passwords Work in Azure?

Azure AD/Office 365 stores passwords for users created ‘On Cloud’ – i.e. the primary record for them exists in Azure AD/Office365. For the ‘On Cloud’ users, password resets are instant, because the same system that hosts the user, manages their password.

Azure AD/Office 365 does not store passwords for your on-premises users. Instead, it uses a password hash. To learn more about this, read Mircosoft’s article on Understanding Office 365 identity and Azure Active Directory. This only functions if you’ve actually enabled password sync, which is a tickbox configurable from the Azure AD Connect side of things.

This means an on-premises user still authenticates against Azure AD/Office 365, but details are synced using Azure AD Connect on a scheduled basis. Someone’s phone number changes? That’ll be pushed to the cloud on the next sync. By default, that sync is every 3 hours. Personally I prefer every hour, but this is going to be dependent on the size of your AD environment if that makes sense.

What about Password changes?

Password hashes are different though. They occur every few minutes – sometimes within seconds. Event logs on the server that hosts Azure AD Connect will show three different events occuring.

The first is the ‘Password Change Request’ Event ID 656. From this you’ll see which user it is, as well as when the password change was actually made according to AD.

Second is the batch count, Event ID 651. This shows that it’s finished collecting details of password changes.

Finally, the Password Change Result record, Event ID 657. This should show the user affected again, and the result of the password change (which is hopefully Success):


I was hoping passwords would almost be instant (within a few seconds) and my original testing showed that, but after more testing I found mixed results. More often it would take a minute or two.

Real World Impact

This means that if you have any application that authenticates against Azure AD, there is a chance of up to a roughly 3 minute delay before Azure AD knows of the new password, and won’t create a great experience for end users depending what applications they use, even first party.

Consider if you had Sharepoint Online for something staff accessed, and someone logs onto their domain connected PC. Their password has expired, so they change it and continue logging in. First thing they do is try and get to the SharePoint Online website, and get prompted for credentials. They try their new password, and it doesn’t work! So they try their old password… but in between these two attempts, their password in Azure AD has now updated. The old password doesn’t work either! From an end user perspective, that’s incredibly confusing.


The real solution to all of the above is to not use Azure AD Connect, and instead use ADFS. Instead of syncing passwords, password requests come from Azure AD back to your on-premises ADFS environment to authenticate a user. This will be immediately aware of a password change, and authenticate the user with the right credentials. You get the added benefit of pass-through authentication to Azure/Office 365 resources, which means users don’t need to keep authenticating to online resources (such as my SharePoint Online example above).

Any questions/comments/disputes on the above? Comment below!

Thanks to @Froosh for confirming my tests on this.