Unable to log in to O365 using ADFS and sub-domains.

I recently came across a problem in a customer tenant regarding sign in for sub-domain users.

ADFS is enabled and sign-in for regular users with primary domain as UPN functions as expected. When a user with a UPN of a sub-domain tries to sign in, the following error message appears in the browser(my apologies for the norwegian text):

AADSTS50107: Requested federation realm object ´{Email hidden}´ does not exist.

The solution involves editing a regular expression in an ADFS claim rule which is used to build the IssuerUri associated with the user’s UPN. It’s described in this article on TechNet and boils down to changing a regEx value.

This is how I did it:

In the AD FS Console:

• Trust Relationships\Relying Party Trusts
• Right-click on ‘Microsoft Office 365 Identity Platform’ and choose “Edit Claim Rules…”
• In the “Issuance Transform Rules” tab, highlight “Issue issuerid when it is not a computer account” then choose “Edit Rule…”
• Take a copy of the existing rule as a backup and then change to this value:

  c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*[.].*)$", "http://${domain}/adfs/services/trust/"));

I found that replacing the entire expression with the one listed above solved the situation immediately, letting the sub-domain users sign in as they were supposed to.
Be aware that this approach could possibly break other stuff in the ADFS service, so you should have a backup of your existing settings to be restored if everything goes south.

Exchange: Renaming of room mailbox, Yeay or Nay?

From time to time we come across scenarios where a meeting room or resource has been removed, relocated or we simply would like it to show another name than the original one in our system.

So, is there an easy way to rename the resource in Exchange and have it reflected in the users calendar for previous bookings?

The answer is Yes, and No.

Renaming of the resource is fairly simple using PowerShell. You have to change the attributes Name, Alias, DisplayName, SamAccountName, and UserPrincipalName.

Set-Mailbox “TestRoom” -Name “NewTestRoom” -Alias “new_testroom” -DisplayName “New Test Room” -SamAccountName newtestroom -UserPrincipalName newtestroom@yourdomain.com

You also have to change the FirstName attribute using the Set-User command:
Set-User “NewTestRoom” -FirstName “NewTestRoom”

So, does this do the trick?

The answer is yes, in regards to new bookings. The problem is that the name change does not reflect in the previous bookings of the resource. The old name will still show in the booking, but if you click on the name of the room, the new name will show in the properties of the resource.

There is no way to change the name of the room without deleting the booking and make a new reservation with the new name. The room is reserved in the system with the old name, and there is no way for Exchange to display the new name in available resources(if you choose Change Room in the booking) without deleting the reservation and making a new one.

Skype for Business Online and PSTN Conferencing

As you all probably know, Microsoft has enabled the possibility of having Dial-in PSTN Conferencing in Skype for Business Online. In order to do this, you either have to have an E5 license plan in O365, or you can purchase the add-on for PSTN Conferencing in your excisting E1 or E3 plan.

PSTN Conferencing is a very valuable add-on to the O365 Skype for Business as it will enhance the possibilities of joining meetings without having to use a client.

To read more about PSTN Conferencing, visit this site on Microsoft.com:

Dial-in conferencing in Office 365

To se which countries have PSTN Conferencing available, check out the list here.

Failed mailbox migration to Office 365: mrsproxy.svc’failed because no service was listening on the specified endpoint. The remote server returned an error: (404) Not Found

I was doing a migration between Exchange 2013 and Office 365 in a Hybrid configuration when I recieved the above error message. Couldn’t quite figure out why until I stumbled accross a forum thread that pointed me in the right direction.

This is what you have to check out and remediate if you have this error:

The ExchangeGuids of on-premise users are different to the ExchangeGuids of the corresponding users in Office 365.

Update the online user’s ExchangeGuid to match the on-premise ExchangeGuid and start migration.

1. On the on-premise Exchange server:

Get-MailBox -Identity userID | Select ExchangeGuid

2. In an Office 365 PowerShell session:

Get-MailUser -Identity UserID | Select ExchangeGuid

If the results don’t match, copy the guid result from command 1 and then run the following command in the Office 365 PowerShell session:

Set-MailUser -Identity userID -ExchangeGuid “copied guid”

Start migration:

$Cred = Get-Credential

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic -AllowRedirection

Import-PSSession $s

$OnPremAdmin = Get-Credentials

New-MoveRequest -identity “UPN” -Remote -RemoteHostName “remote host ex OWA URL mail.domain.com” -RemoteCredential $OnPremAdmin -TargetDeliveryDomain domain.mail.onmicrosoft.com

Skype for Business Cloud PBX with PSTN Calling – 5 Steps to Success

This is a great post done by Skype4B enthusiast Mark Vale on Cloud PBX and Office 365 E5 which is to be launched in the US on December 1st 2015. I recommend everyone to read his thoughts and keep them in mind.

Source: Skype for Business Cloud PBX with PSTN Calling – 5 Steps to Success