Azure

Remove Microsoft Account or Work Account

If you’re using Office 365 and/or Azure, you may have run into this scenario. If you want detailed information about Microsoft Accounts vs Work or school accounts, read this¬†comprehensive article.

For people who set up a Microsoft Account on a work email address, and then configured it for Office 365/Azure, you’d be used to seeing this screen every time you log in:

It’s necessary, but annoying when you’re signing in a lot. I’m not sure how long this has been around, but you can change the email address associated with your Microsoft account, and move it away from your work email address.

And you may notice, there’s that ‘Tired of seeing this?’ message. My brain blocked that out, so you can follow that link too ūüôā

Atwork¬†have a writeup on how to change the email address (the first link gives a 404 message, but you’re still in the right place to make the changes). I tested this on my own account, and within a few minutes I was no longer seeing the choice between Work or Personal when signing into Office 365/Azure services.

Combine that with ADFS or Azure AD Connect Pass-Through Authentication to make your Microsoft sign-ins a quicker process!

AzureAD – Assign Application to User via PowerShell

Scenario:

You’ve created an application in Azure AD, and want to script allocating access to the app rather than using the web interface. App show up at¬†https://myapps.microsoft.com

Azure AD Premium is required for group access which would be ideal, but if you don’t have that you’ll need to add access on a user by user basis.

Answer:

PowerShell of course. First, you’ll need Azure AD for PowerShell (Preview version 2.0.0.17 at time of writing).

The below script which I modified from Philippe’s comment here¬†should cover both internal, cloud and B2B invited users. The original script was using -objectid rather than -searchstring which works better and is more accurate for the internal and cloud accounts, but doesn’t work at all for B2B accounts.

The AppID can be obtained from this command:

Get-AzureADApplication -SearchString “Display Name for App”

Put the corresponding AppID into the below script, and you’re good to go. You’ll get prompted for Azure AD credentials as per usual. You can also get this

This is designed for a single user addition, but you could easily import the email addresses from a CSV file, and do a ‘for each’ on each entry like I did here.

# The UserPrincipalName or ObjectId of the user
$userId = “email@contoso.com”

# The AppId (a.k.a. “client ID”) of the app to assign the user to
$appId = “AppIDGoesHere”

# Connect to Azure AD
Connect-AzureAD -Confirm

# Get the user to be added
$user = Get-AzureADUser -searchstring $userId

# Get the service principal for the app you would like to assign the user to
$servicePrincipal = Get-AzureADServicePrincipal -Filter “appId eq ‘$appId'”

# Create the app role assignment
new-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId -PrincipalId $user.ObjectId -ResourceId $servicePrincipal.ObjectId -Id ([Guid]::Empty)

 

Note: If you try this and get the error below, it’s because the app is already assigned.

new-AzureADUserAppRoleAssignment : Error occurred while executing NewUserAppRoleAssignment
StatusCode: BadRequest
ErrorCode: Request_BadRequest
Message: One or more properties are invalid.
At Z:\script.ps1:17 char:1
+ new-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId `
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-AzureADUserAppRoleAssignment], ApiException
+ FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.NewUser
AppRoleAssignment

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.

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:

aad

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 mydomain.com, it was set to mydomain.local – another valid internal domain to Active Directory, but not one that Azure Active Directory knew about:

aad2

The unknown domain caused Azure Active Directory to disregard it, and instead use it’s default tennancy domain of wrong.onmicrosoft.com. I thought just changing the dropdown menu to mydomain.com 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 “existinguser@mydomain.local” -NewUserPrincipalName “existinguser@mydomain.com”

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*”

Easy!

Azure AD Connect 1.1.105.0

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: https://www.microsoft.com/en-us/download/details.aspx?id=47594

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:

azure2

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.

azure1Success!

Update: 1st March 2016

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