As part of a project, Thaddeus Kurowski (CDW) and I put together a Skype test matrix to ensure that the implementation worked as designed/expected.
You may find it useful as well.
https://gallery.technet.microsoft.com/Skype-Implementation-Test-e11edf07
YMMV.
This morning, we resolved an issue that I have never seen before, and hope that I never do.
I tell customers during design sessions that if there are existing network issues, Skype (or Lync) is going to find them. If there is something a bit wonky, we are going to discover the wonkiness. And here we go.
Skype edge with 1:1 Nat. Public IP is 71.16.x.x. Edge server is doing the classic 3 IP thing. Remote logins are fine. Everything seems to be ducky. Except we cannot talk outbound.
Go check all the network again. Looks good. Check the topology, servers, IP assignments, paths. All good. Certificates, the common culprit behind one-way federation and presence look good. We are now scratching our heads. We know now we are looking at something wonky, but what?
I was under the impression that 1:1 NAT is 1:1. But it turns out that a Watchguard Firebox is capable to doing 2:1 NAT. Inbound to the Edge server worked because the firewall had 1:1 NAT from public to DMZ VLAN. Edge trace logs showed subscriptions and connections timing out on the far side. The connections were being made, just no return traffic. No SYN. Telnet client testing outbound from the edge server on 5061 ad 443 worked. Clearly inbound connections were working or there would be no remote logins.
As long as the traffic originated from outside the organization, things worked fine and the Edge server, via the 1:1 NAT was responding as expected to the source IP. But traffic originating from INSIDE the organization was failing. One way presence, presence unknown, cannot send to user, etc. Apparently…
…according to www.ipchicken, the Watchguard was sending all traffic from the DMZ external VLAN out via a completely separate set of addresses! HUH? Whaaaaat? So inbound would work, but outbound went out on a separate address?
So their firewall guy fixed that, we are back to 1:1 NAT and all is good. Something to be aware of, eh? Go figure.
YMMV
I will not attempt to embellish this content past commenting that this call failure is not common. I have rarely seen it, most likely because my implementation practice for upgrades is to match system settings before testing.
Having said that, I think I would have thought the initial setup described here would have worked. But apparently not. Inbound calls follow the original port. Something to be aware of.
Thanks to Josh Walters, CDW Senior Consulting Engineer for writing this up for us.
YMMV
Scenario:
Customer is deploying a new 3-node Skype for Business Enterprise Pool to replace their existing 2-node Lync 2010 Enterprise pool. Enterprise voice is enabled in Lync 2010 and Lync call traffic is directed inbound from their PRI and delivered to an Avaya Session Manager appliance, then it is delivered to Lync. Internal call flow functions as below:
PRI --> Avaya Aura System Manager --> Lync 2010 Enterprise Pool
After deploying the new Skype for Business FE Enterprise Pool, Edge Pool, and Back-End we decided to migrate a test user who was enabled for Enterprise Voice to the new Skype for Business Pool and test call flow with the new infrastructure. The new expected call flow should function as below:
PRI --> Avaya Aura System Manager --> Lync 2010 Enterprise Pool --> Skype for Business Enterprise Pool
After moving the user, the user was able to successfully place an outbound call to both internal and external recipients but was unable to receive an inbound call. When attempting to dial the Line# for the migrated user we were being routed directly to Voicemail (Exchange 2010 Unified Messaging). What gives?
Inbound Traffic
Avaya Aura System Manager --TCP 5060--> Lync 2010 Enterprise --TCP 5060--> Skype for Business Enterprise
Outbound Traffic
Skype for Business --TCP 5060 or TLS 5067--> Lync 2010 Enterprise --TCP 5060 or TLS 5067--> Avaya Aura System Manager
Well, what we found was that Avaya was routing SIP traffic to Lync 2010 using TCP port 5060 only (as seen above). When Lync 2010 received the SIP request it attempted to route the traffic to the Skype for Business pool where the user is homed and it tried to use the same port it received the traffic on, but we had not yet activated TCP on the Skype for Business pool for Mediation. The Skype for Business pool was therefore rejecting the traffic and then sending the call to Voicemail.
The fix: Enable TCP (and make sure to use the correct port for YOUR environment) so that the Skype for Business pool is listening for traffic on said port. After enabling TCP 5060 on the Mediation Server (Collocated) all inbound call routing for the user started working.
Existing Office 365 tenant successfully using SfBO. Exchange on-premises. Azure AD Connect version unknown, but up and functional PBX with voice mail on-premises. We extended schema and installed SfB on-premises with Edge. Modified the firewall to specification and attempted to get into hybrid.
DNS mods we easy. Creating a test user and synching up to O365 went fine. Enabling the test user for SfB went fine. Another AAD sync and we were in business. Moving the test user to O365 (so we could test moving back to on-premises) went just fine. And there the problems began. Attempts to move the user back to on-premises failed with the following non-help message:
PS C:\Source\scripts> move-csuser -Identity sfb.test3@domain.com -Target domain-sfbfe01.domain.com -Credential $cred –HostedMigrationOverrideUrl https://admin0a.online.lync.com/HostedMigration/hostedmigrationservice.svc -Verbose
VERBOSE: CN=sfb test3,OU=hometown_Users,OU=domain_Users,DC=domain,DC=comConfirm
Move-CsUser
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Y
VERBOSE: Validating parameters for move operation.
VERBOSE: Calculating new server information for user [domain-sfbfe01.domain.com].
VERBOSE: Moving user [sip:sfbtest3@domain.com] across deployments.
VERBOSE: Creating source external move endpoint.
VERBOSE: Validating the hosted migration override URL provided:
[https://admin0a.online.lync.com/HostedMigration/hostedmigrationservice.svc].
VERBOSE: Retrieving web ticket URL.
VERBOSE: Retrieving live id token.
VERBOSE: Initializing source external move endpoint.
VERBOSE: Creating target external move endpoint.
VERBOSE: Initializing source external move endpoint.
VERBOSE: Validating user [sip:sfbtest3@domain.com] online, for on premises to online move.
move-csuser : Index was outside the bounds of the array.
At line:1 char:1
+ move-csuser -Identity sfb.test3@domain.com -Target domain-sfbfe01.domain.com -Credenti ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (CN=sfb test3,OU...,DC=domain,DC=com:OCSADUser) [Move-CsUser], IndexOutO
fRangeException
+ FullyQualifiedErrorId : MoveError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsUserCmdlet
"Index was outside the bounds of the array."
You know how many hits googlepedia produces for that? None of them helpful. So we triple-checked our work. Reviewing the overall picture, it was apparent that there was some issue with the on-premises environment, but everything we looked at came up good.
The root cause was that Azure AD Connect was installed and configured BEFORE the extending schema for SfB. As it turns out in the end, Azure AD Connect does not refresh schema very well, if at all, unless you tell it to.
And even then, maybe not. There is a button inside the missclient (Synchronization Service Manager) that SAYS it will do it. I mean, it clearly says “refresh schema”
…and the following message sure says it will…
But, guess what, that is not the case.
As you can probably guess, the root issue causing our migration failure was that the AAD Connect had no knowledge of the SfB attributes coming in with the online user. Now, I would have thought they would have seeing as how we were successful in installing SfB, creating a good on-premises user, and moving that user up into the tenant. But no.
Interesting side note is that once we twigged onto the schema concept, using the button on AAD connector populated SOME valiues – we could see them. But still moving back to on-premises failed.
It seems that if you run "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe", you get a few options. Specifically, take a look at the third option from the top.
I do not pretend to know the difference between “refresh schema” in one location as opposed to the other, but I do know that running the “refresh directory schema” from this location, followed by a full synch on both connectors resolved our failed user moves.
Keeping your Azure AD Connect up to date might be helpful also and in theory the reinstallation process will trigger a schema refresh. You can get a clean copy of that installer right here.
Of course, once you know what to look for, there is this also.
YMMV
I feel a bit like Steve Martin…
AudioCodes is due, very shortly I hope, to publish new firmware for the 440HD and 450HD phones (dare I hope for the 430HD also? 405? 405HD? 420HD?) that enables the device to do a web sign-in to an MFA-enabled Office 365 tenant account. Wow, that was one long sentence. My English prof at St Thomas Aquinas would beat me about the head and shoulders. However, there it is.
Let’s walk through this process.
Update the firmware on the phone device. How you do that is up to you. Personally, I used my IP Phone Manager Express.
My 440HD at 3.0.1.89, my 450HD is at 3.0.1.63.214. After getting the firmware updated, both devices appeared to be the same. I am sure there is some detail that I did not notice, but they look the same to me.
Open either the web interface, or the phone screen, and start the sign-in process.
phone:
phone web interface:
select the web sign-in option….
What results from either method is this:
or
Inside the red box (which you will not get on your phone or browser screen) is the two critical pieces of information to complete the login process. First is the URL http://aka.ms/sphone. Go there with your code.
The code is not case sensitive.
So you go to the indicated URL and follow the prompts, then enter your code. You will see where I did lower case while the phone and the browser GUI both indicated caps.
What follows is a bit round-about – but you get thrown into the office portal login…
and a redirect to the corporate AD sign-in…
and after working my way through the MFA routine, I get this:
after entering the requisite code… remember, not case sensitive, the page magically morphs to this:
Select continue, because I am assuming you WANT to get the device to work…and you get this
For you eagle-eye readers, you will note that now this page, which appears to look just like a few steps before now says I am signed in. How nice. Observing the device, I note that it SAYS it is logged in, but you know, it still looks pretty unusable at this point. So, click on your account that was signed in…
Wala!
and now the device itself looks like the following – well, it will in a bit – patience padiwan!
BTW, you have 15 minutes to complete the web sign-in gymkhana. If you blow the 15 minute limit, you will need to start over.
I am told, by an source who only spoke on the condition of anonymity (this makes me equal to all the reporters in any nation’s capitol), that we can expect this new firmware code to be out in the wild sometime around the end of Q1 2017.
YMMV
