Office 365 Microsoft Phone System Call Queues

It has been a while since my last blog post I have been busy doing lots of deployments. So expect more post over the coming weeks.

This one will be a relativity quick one. Whilst working on a customer deployment for Microsoft Phone System fully in the cloud the customer wanted to setup some call queues and auto attendants which was great. All setup and away we go however on testing if anyone ever called the call queue all they just got was the music on hold and the people assigned to the queue never got the SfB notification.

So checking everything once , twice everything looked right but nope it still wasn’t working!

I sat back and looked at how the whole SfB was configured in the Cloud and noticed that the customer had closed their federation. So I added their own public domain to the allowed federation list and waited 15 minutes then BOOM it started working.

So point to note if anyone closes their federation ensure they add themselves as a federated domain in SfB Online!

Also another little nugget I found is the following site which allows users to manually opt out of a queue if they want to do so – https://mysettings.lync.com/pstncalling

Advertisements

Configure Lync/SfB with Office 365 for server to server authentication

Recently I was advised there were a lot of events being generated from a customers Lync server where they had recently migrated all their mailboxes to Office 365 but were using Enterprise Voice on premise. The event being generated was as follows:

Event ID – 32053 from the LS Storage Service – Storage Service had an EWS Autodiscovery failure.

I won’t past the whole error here but the crux of the error was as follows:

“ExchangeAutodiscoverException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=adam@domain.com, Autodiscover Uri=http://autodiscover.domain.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL> —> Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The request was aborted: The request was canceled. —> System.Net.WebException: The request was aborted: The request was canceled. —> “

Now looking into this the Lync server could not create the connection to Office 365. I could see Autodiscover is working and the server could get a logon prompt if they hit the URL.

So I decided to check the OAuth Configuration – get-csoauthconfiguration and could see the URL for Exchange Autodiscover was set correctly however the clientauthorizationoauthserveridentity was still pointing at the hybrid exchange management server. So it lead me onto how do you setup an OAuth trust between a cloud service and on premise servers?

Well luckily enough help is at hand and I will try to guide you through the process…

First of all you must connect to PowerShell for the MSOL service in O365 and run the following get command:

  1. get-cstenant and then grab the displayname of your Office 365 tenancy.
  2. Fire up a Lync/SfB On Premise PowerShell Management Session – and then run the following command –
    New-CsOAuthServer microsoft.sts -MetadataUrl "https://accounts.accesscontrol.windows.net/"Displayname"/metadata/json/1" where "Displayname" is the name you got from step one
  3. Then run Get-CsPartnerApplication “microsoft.exchange” – If you get a result then carry out step 4 if not move onto 5
  4. Remove-cspartnerapplication “Microsoft.Exchange”
  5. New-CsPartnerApplication -Identity microsoft.exchange -ApplicationIdentifier 00000002-0000-0ff1-ce00-000000000000 -ApplicationTrustLevel Full -UseOAuthServer

Once this is complete you have configured Lync/SfB to use the Office 365 OAuth servers and you will start to see the following errors in the Event Log

Event ID 32054 – LS Storage Service – Storage Service had an OAuth authentication failure. CreateAppActAsToken failed, ex=OAuthConfigException: code=ErrorOAuthSts, reason=Recv RST response, failed, sts=https://accounts.accesscontrol.windows.net/a26842db-0e87-4d85-b745-9b7bf0f96067/tokens/OAuth/2, resource=00000002-0000-0ff1-ce00-000000000000/autodiscover-s.outlook.com@domain.com, ex=The remote server returned an error: (401) 

This s fine at this stage as we haven’t created the trust between on premise and Office 365 yet.

  1. Connect to Office 365 MSOL PowerShell whilst importing the following module : import-module MSOnlineExtended
  2. Run get-MSOLServicePrincipal – This will return lots of results but you are specifically after the one with the displayname “Microsoft Lync Server”
  3. Now at this stage I have made an assumption and that is that the OAuth certificate used by the Lync/SfB server on premise is up to date and is available to be exported. If not renewal this!
  4. Open up the MMC for certificates and identify the exact certificate currently assigned to Oauth for Lync/SfB this is generally an internal certificate. Export it as a X.509 Base64 (Which is not the default)
  5. Then run the following PS script where the line certificate.import contains the location of the exported certificate:
  6. $certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
    $certificate.Import("C:\Certificates\Office365.cer")
    $binaryValue = $certificate.GetRawCertData()
    $credentialsValue = [System.Convert]::ToBase64String($binaryValue)
  7. New-MsolServicePrincipalCredential -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 -Type Asymmetric -Usage Verify -Value $credentialsValue -StartDate 02/12/2015 -EndDate 01/12/2015
  8. Now for the above command there are two items to be bear in mind first of all the startdate cannot be before today and the enddate can only be for a period of one year so even if the certificate lasts longer this setup can only last for a year!
  9. Get-MsolServicePrincipalCredential -AppPrincipalId 00000004-0000-0ff1-ce00-000000000000 - The Returnkeyvalue is "Asymmetric"
  10. Then you should get a result with your certificate with the dates specified.
  11. Finally you need to set the set-cssoauthconfiguration -exchangeautodiscoverurl from https to http as currently https will not pass the tests and also flag up errors. This is done from the on premise Lync/SfB Management shell

Then you should be able to run test-csexstorageconnectivity -verbose and get a test passed result!

You should also see an event with ID 32048 where it states “OAuth was properly configured for Storage Service.

CsOAuthConfiguration validly configured”

Finally when you need to renew your setup which will be every year you will need to remove the MSOLServicePrincipal and replace it with your new certificate using the above process!

 

Mailbox fails to move with a 404 error no service listening

So I was moving some mailboxes the other day and had a batch of mailboxes and two of them in the batch wouldn’t move it showed errors similar to the following:

Error(s): The call to https://mail.vanitydomain.com/ews/mrsproxy.svc failed because no service was listening on the specified endpoint

Error details:
There was no endpoint listening at https://mail.vanitydomain.com/ews/mrsproxy.svc that could accept the message this is often cause by an incorrect address of soap action. The remote server returned an error 404 not found.

However all the other mailboxes would sync just not these two. After further digging I found that these mailboxes had recently been converted from user mailboxes to shared mailboxes.

What I then did was to compare the Exchange GUID to see if they matched from on premise which they didn’t!!!

So to fix this I ran the following:

On Premise Exchange Powershell

get-mailbox “mailboxname” | fl ExchangeGUID

Office 365 Exchange Online Powershell

Set-mailuser “mailboxname” -ExchangeGUID “Result from above command”

Then as if by magic the move kicked into life and migrated successfully.

My scenario is Exchange 2013 CU9 hybrid with the legacy as the same version, however there is reports of Exchange 2013 CU2 hybrid’s with same issue!

Office 365 Auto Attendant with Lync 2013 On Premise

In my previous post I discussed Unified Messaging for the Voicemail feature of Office 365 with Lync 2013 on premise now in this article I will discuss how to configure the auto attendant in the same scenario.

Within The New Office 365 portal (Wave 15)

Select Dial Plan in O365 tenant > under UM Auto Attendants click + and fill out the information you can enable this straight away or come back and enable later on.

auto attendant

Then select the new Attendant and set the following as per the currently deployed options or query with customer.

general

greetings

business hours

menu

address

dialling author auto

Then with Lync 2013 on premise open PS and run the following command to create the account:

  • New-CsExUmContact –sipaddress SIP:EX_AA_365_SA@yourdomain.com -RegistrarPool “FEpool.com” -OU “OU=Blah,DC=yourcompany,dc=com” -DisplayNumber “+14255550101” -AutoAttendant $True
  • Grant-cshostedvoicemailpolicy –identity “post the GUID that has been created” –policyname CloudUM

Then within Exchange Online Powershell

  • Set-UMmailboxpolicy -identity “Policy Name in O365” -SourceForestPolicy “CloudUM”

Viola auto attendant should be ready to go. Bear in mind the settings show here are pretty much the defaults and can be changed as you choose.

Office 365 Unified Messaging with Lync 2013 On Premise

Update – 30/04/2018 – Minor changes

UPDATE – 13/01/16 – Further updates and some tasks removed. Also note this does not contain any information for configuring Cloud PBX using UM in O365.

UPDATE – 10/06/15 I have also tested this configuration with Skype for Business and Exchange 2013 SP1 RU5 Hybrid with the current Office 365 wave.

————————————————————

I recently was working with a customer who had Exchange 2010 SP3 on premise but wanted to move all the functionality onto Office 365 whilst keeping Lync 2013/SfB 2015 on premise as this was the companies telephony system. No sweat I thought, well this blog is a list of my findings and how to actually get it configured. We will start with Voicemail and then discuss Auto attendant later on.

Lync 2013/SfB 2015 Enterprise Voice On Premise – Exchange 2010 Sp3/ 2013 CU11 Hybrid with The New Office 365 tenant (Wave 16)

First of all open up a PS shell on your Lync/SfB FE on premise then run:

  1. Set-csaccessedgeconfiguration –allowfederatedusers $true
  2. New-CsHostingProvider -Identity “Exchange Online” -Enabled $True -EnabledSharedAddressSpace $True -HostsOCSUsers $False -ProxyFqdn “exap.um.outlook.com” -IsLocal $False -VerificationLevel UseSourceVerification
  3. Get-csmanagementstorereplicationstatus ( to ensure replication has occurred between all Lync/SfB servers make sure they all say true before moving on)
  4. Get-cshostingprovider -localstore to show the following
  5. Cshostingprovider
  6. Set-CsAccessEdgeConfiguration -UseDnsSrvRouting -AllowFederatedUsers $true -EnablePartnerDiscovery $true
  7. New-CsHostedVoicemailPolicy -identity CloudUM -Destination exap.um.outlook.com -Description “Office 365 Voicemail” -Organization “tenantname.onmicrosoft.com” (Ensure you use the tenant name and NOT your on premise domain otherwise the traffic will not route and this will not work)

Log onto the O365 Wave 16 tenant

Go to Unified Messaging > UM Dial Plans > New

new um dial

Then Edit the Dial Plan > Configure

For this you should try and match the company’s on premise configuration so that it matches but below is an example:

configure

dial codes

outlook voice access

Under the Outlook Voice Access numbers also add the number without the E164 format and any shorter version such as 3/4/5 digits.

settings

dialling rules

dialling auth

transfer

Then on premise Lync 2013/ SfB 2015 you need to create the Exchange UM Contact for O365 within Lync/SfB Powershell

  • new-csexumcontact -displaynumber +44203XXXXX –sipaddress SIP:EX_UM_365_SA@yourdomain.com -registrarpool  yourpool01.youcompany.com -ou “OU=User,DC=yourcompany,dc=com”
  • Grant-cshostedvoicemailpolicy –identity “post the GUID that has been created” –policyname CloudUM

Then switch to Exchange Online Powershell

  • Set-UMmailboxpolicy -identity “Policy Name in O365” -SourceForestPolicy “On Premise UM Policy Name”

Then finally on your on premise Exchange 2010 SP3/ Exchange 2013/2016 server (Note this is only if Unified Messaging is already configured on premise so that when you migrate a UM mailbox it doesn’t fail otherwise if you don’t run this step the remote move request will fail)

  • Set-UMmailboxpolicy -identity “On Premise UM Policy” -SourceForestPolicy “Policy Name in O365”

The Very last step is to configure the user. Now if you are setting up UM brand new then carry out the following steps but if you are migrating a user then ONLY carry this out after the user has migrated to Office 365 or you have suspended the move before completion. As otherwise UM will route to the cloud and until the mailboxes exists the voicemail message will never be delivered to the end user. As you cannot have a split UM in cloud and mailbox on premise and vice versa.

Within Lync 2013/ SfB 2015 PowerShell

  • Grant-cshostedvoicemailpolicy –identity “accountname” –policyname CloudUM
  • Run get-csuser –identity “accountname” and check that hostedvoicemail is set to true if not run the following command.
  • Set-csuser –identity “youraccount” –hostedvoicemail $true

 

Exchange 2010 OWA Redirects

If you are in the process of migrating from earlier versions of Exchange such as Exchange 2003 to Exchange 2010 or even to Office 365 URL redirects is a very useful setup to allow a single URL to re direct to multiple locations depending on where users are hosted.

To enable the re direction of 2003 OWA on the 2010 Exchange server open PowerShell and run the following command:

Set-OwaVirtualDirectory “OWA (Default Web Site)” -Exchange2003Url https://mail.customer.com/exchange

Also depending on customer requirements you can also configure the OWA redirect so all users go to https://owa.customer.com and get re directed accordingly to either https://owa.customer.com/owa or https://mail.customer.com/exchange. To re direct all the traffic in the 2010 Exchange go to the IIS MMC and set as shown below:

Warning: It’s very important that you check the checkboxes exactly as shown in the screenshot above!

Once this step is complete, you need to remove the enforced redirect from each of the virtual directories under the Default Web Site. To do this, select each virtual directory individually, and then open the HTTP Redirect property and uncheck the “Redirect requests to this destination” checkbox. You’ll need to do this on the following virtual directories:

  • aspnet_client
  • Autodiscover
  • ecp
  • EWS
  • Microsoft-Server-ActiveSync
  • OAB
  • PowerShell
  • RPC

If the customer wants to browse http://cas01.customer.com, you’ll get an HTTP 403.4 error at this stage. This is because SSL is required at the top-level website. In order to get the redirect working, we need to disable SSL for the toplevel website while leaving it enabled for the relevant child virtual directories.

Select the Default Web Site and open the SSL Settings properties. Uncheck the Require SSL checkbox as shown below:

Like the redirection settings, this change will be inherited down the tree for any virtual directory which does not explicitly set the setting independently. Ensure that SSL is required for the following virtual directories:

  • Autodiscover
  • ecp
  • EWS
  • Microsoft-Server-ActiveSync
  • OAB
  • owa
  • Rpc

Warning: If you require SSL for the PowerShell virtual directory, you will render Remote PowerShell inoperable!

Once you’ve configured the redirection and SSL settings, open a command prompt and run iisreset.

OCS Federated IM’s only working one way

Recently after implementing my Edge services in OCS we started to federate with our partners and all seemed rosy to start off with. Then all of a sudden we could only send IM’s out and could not receive any back. External partners would send us an IM we would get the OCS toast but when you accept it the conversation was blank.

Well after much checking and doubling checking everything!!! It turned out that the primary EDGE certificate that had our domain name was the incorrect way around as our users SIP address end in a different domain name. So if anyone else is working in a multi domain environment make sure the primary name or your certificate is the same as your users SIP address!