Sunday, April 8, 2018

Skype for Business Online - Additional Emergency Locations in PowerShell

Assigning a phone number to a user in Skype for Business Online requires you to first assign an Emergency Location. The Emergency Location is used for saftety and liability purposes in case someone were to dial an emergency number (ex: 911 in the USA). The location is sent to the PSAP (Public Safety Access Point, i.e. police, firefighter, ambulance, etc) so they can show up to the correct address and provide help.

Take a look at the picture below from my tenant. Notice under 'Dallas,' my address is listed.  Underneath 'Dallas' is my actual apartment number (all addresses blacked out for privacy). Skype for Business Online allows for a parent/child relationship with Emergency Locations. For example, if there are multiple floors in a building, you could create a parent location of 'Minneapolis Office' with each floor of the building as a child item (Floor 1, Floor 2, etc).

While this flexibility is great, it presents problems when assigning Emergency Locations in bulk for new users. Lets say I want to assign 50 users to an additional location listed under 'Dallas' above. I haven't found a good way to bulk assign locations in the admin panel, so I'm going to use PowerShell instead.

The command 'Get-CsOnlineLisCivicAddress' lists all Emergency Locations with one cavaet - it doesn't list any of the 'additional locations'. Why? I have no clue, and frankly, it's kind of annoying. So how do we get the list of additional locations? Here's a command I've found useful:

Get-CsOnlineLisLocation|Where-Object {$_.location -ne $null}|ft description, location

When I run this command on my tenant, here's what I see for my apartment in Dallas:

So, how do I assign additional users to this location? The 'Set-CsOnlineVoiceUser' cmdlet takes a'locationid' object.I can get the'locationid' from the 'Get-CsOnlineLisLocation' cmdlet in our previous step and set the 'location' object to be the location I found running the 'Get-CsOnlineLisLocation' command above:

Now we can use the 'locationid' within the 'Set-CsOnlineVoiceUser' cmdlet to set the Emergency Location for a user to an additonal location listed underneath an Emergency Location:Set-CsOnlineVoiceUser -identity joshc -telphonenumber +19725551212 -location id 87b77092-4945-9824-38ada04012e7

If anyone has found a better way of dealing with 'additional locations' within PowerShell, feel free to leave a comment below.

Monday, January 8, 2018

Exchange Unified Messaging - Does Anybody Really Know What Time it is? (Your Edge Servers Really Should...)

Greetings and Happy New Year! I hope everyone's 2018 is off to a great start.

I received an interesting problem recently that I wanted to share. Below is an email from a client (I'm paraphrasing):


Exchange Unified Messaging (UM) is no longer working internally. People can call in from the outside, reach UM, and leave messages just fine. However, our own internal users cannot call eachother and leave a voicemial. Calls internally either go to dead air or receive a busy signal. 

Is this something you can help us out with?"

Of course I can help! 😃

The client has a hybrid environment with their S4B severs on premise and Exchange environment in the cloud. Since UM must reside in the same place as the Exchange mailboxes, their UM environment resides in the cloud as well. The customer connects to their O365 tenant via Edge federation (this will be important later 😉).

I decided to take a trace via CLS logger on the FE server of a failed internal VM call and noticed the following error:

SIP 429 Provide Referrer Identity

ms-diagnostics: 1020;reason="Identity of the referrer could not be verified with the ms-identity parameter";ErrorType="Invalid signature";Referrer="";HRESULT="0xC3E93EE0(SIP_E_CRYPT_REFERRER_DATE_SKEWED)";cause="Invalid signature";signer="";source=""
ms-edge-proxy-message-trust: ms-source-type=EdgeProxyGenerated;;ms-source-verified-user=verified

 I've bolded the part of the error above that helped me fix this issue. I only half understood what the error was trying to tell me - the date on the Edge pool is somehow 'skewed' and incorrect. I hadn't seen this error before, so some further research was needed.

A quick Google search pointed me to this article mentioning the exact same error the client was having. I logged onto one of the two Edge servers in the pool and noticed the same error mentioned in the article linked above:

The clock on the second Edge Server in the pool was six hours behind the current time. The customer had rebooted to install updates approximately two weeks before the error occurred and the clock never re-synced. Judging from the error in the event logs above, my guess as to why UM was not working is that for 'crytographic verification' to occur (i.e. TLS traffic via the Edge Server to O365) the time of the request must match between the two systems.

After adjusting the clock manually on the offending Edge Server, I had the client re-test and everything was working again. Yay!

Before I sign off, I must pay homage to the band Chicago. They were the true 'inspiration' for the title of this post 😉. 

Heck yes that is a keytar