Skip to main content

Tag: exchange

Exchange 2016 Updates: Don’t forget to activate the components!

jimmy Leave a comment

I’ve done a number of Exchange and Skype for Business server deployments over the last year, and recently I moved to Exchange 2016 versus 2013 just to get the deployments up and running on the latest. However, after performing my upgrade to Exchange 2016 (per these instructions), my EWS connections between Skype for Business and Exchange were not working correctly. Of course, Exchange isn’t fully running for anyone, I’m still testing things out, so not a big deal, but still. What the hell is going on?

In S4B, when I run Test-CSExStorageConnectivity, I’m getting “Test-CsExStorageConnectivity : ExCreateItem exchange operation failed, code=50043”.

testcsexstorageconnectivityerror

The standard response, and search result in Google, for a 50043 error is to check and make sure that your “ExchangeAutodiscoverUrl” property after running Get-CSOAuthConfiguration is configured for the Exchange server’s autodiscover metadata json URL (“https://<exchangeAutodiscover>/autodiscover/metadata/json/1”). But what happens if you’ve already checked that? The URL is correct and you’re good to go, so what changed?

Wait, didn’t I say I upgraded to the latest Exchange 2016 CU (CU3)? Did I completely follow the instructions?

Hmm..let’s check the Exchange server components (something new, AFAIK, to Exchange 2016):

Well. Guess I didn’t the follow instructions at the end that states you to have run the following:

Set-ServerComponentState EX2016SRV1 –Component ServerWideOffline –State Active –Requester Maintenance

followtheinstructions

I’m going to start tagging moments like this as ‘ya dummy’ moments.

Now, let’s check the component status:

get-servercomponentsactive

And then running Test-CSExStorageConnectivty works, and all is well.

So I guess one thing to look at if you’re getting a 50043 error and your have the Metadata URL correct is to verify that EWS is running on your Exchange box.

Skype for Business/Lync Server and Exchange UM: Errors with Event IDs 1079 & 1136

jimmy Leave a comment

During a recent Skype for Business-Exchange 2013 deployment, I tried running all calls to a DID, then to an Exchange 2013 UM Auto Attendant. After some hiccups I had it working, but painfully, dialing by extension and transfers did not work from the Auto Attendant. After doing some investigating, the Skype server wasn’t giving me an errors, and my syslog from the Audiocodes gateway was indicating calls were transferring.

However, the Exchange server gave me two errors regarding unified messaging: 1079 and 1136.

1079:

exUMError1079

1136:

exUMError1136

I tried lots of solutions, tested my environment numerous times, but nothing was working. If you look these errors up when doing a Skype for Business server deployment, you’ll often see Microsoft KB 3069206 come titled, “Exchange UM Auto Attendant cannot transfer calls to a phone or extension number in Skype for Business Server 2015“. Looks great and promising…

…but I’ve already updated the server to the latest CU.

With more Google-fu, I found my solution: I needed to change my certificate for the Exchange server.

According to this TechNet thread, the certificate assigned to the UM services on the Exchange server needs to have it’s subject name be the same as the Exchange UM server’s name. I had used the same UCC-SAN cert for UM services that I set up for the Skype for Business Edge server, and added all the subject alternative names needed.

The fix: perform a new certificate request from the internal CA, apply the certificate to the UM services, then restart the UM services on the Exchange server..

After that, call transfers worked!

Hope this helps someone.

 

Creating New Powershell Virtual Directories in Exchange 2013

jimmy Leave a comment

I encountered the most bizarre issue: after removing my Powershell Virtual Directory, I could not for the life of me recreate the VD. I continually received the following error:

New-PSSession : [subdomain.mail.domain.com] Connecting to remote server mail.domain.com failed with the following
error message : The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. For more information, see the about_Remote_Troubleshooting Help topic.

Nothing online was helping, until I read something randomly about adding the Exchange Snap-In in a regular Powershell window. So I typed the following in Powershell:

add-pssnapin Microsoft.Exchange.Management.PowerShell.SnapIn

Bingo. Directory created.

Weird.