The Exchange server won't let us connect
I have one user, where the SfB client won't connect to the Exchange mailbox in Exchange Online This is the error message 'The Exchange server won't let us connect. We're working on fixing the connection. Your history, voice mail and Outlook features might be unavailable or out-of-date until things are fixed.' Other users on the same On-Premisses SfB pool, with an Exchange Online mailbox are working Any ideas of what the problem might be?
EWS integration from SfB client to Exchange during a cross forest migration
Summary During a cross forest migration, a single forest (source forest) is moved to a new single forest (target forest). The users and services (AD, Exchange, Skype for Business and SharePoint) are moved in different phases from the source forest to the target forest. The new services such as Exchange and SfB are already implemented in the target forest and can already be used for tests (function, migration). The existing SIP/E-Mail domain will be reused in the new environment. So the SfB migration cannot be done in phases but must be done in one step ("Big Bang"). Challenge EWS is used for the client-side integration of the SfB client into the Exchange mailbox. A functioning autodiscover is required for this. The SfB client only uses the autodiscover via DNS. This is only one mechanism of the available Autodiscover mechanisms that Outlook can use. This integration via EWS should ideally be maintained at any time during the migration. Since the Exchange mailboxes are phase-wise converted, the situation arises that the DNS entry (autodisocover.domain.de) does not always point to the correct mailbox. This means that if the user's mailbox is switched to the new environment and the Autodiscover DNS entry still points to the old environment, the Skype Client will also connect to the old mailbox. So a data loss of the Conversation History is pre-programmed with the later conversion of the Autodiscover entry. Considerations With the Exchange migration the TargetAddress (AD attribute) with reference to the old Exchange mailbox (source forest) is set in the target forest before the mailbox migration. The TargetAddress can be understood as a forwarding mechanism. If the mailbox migration is successful and the CutOver is completed, the forwarding is removed from the target mailbox and is added to the source mailbox with a reference to the target mailbox. The assumption would be that the SfB client also makes an autodiscover request for the TargetAddress domain. This functionality seems to exist in the Outlook client. The advantage would be that we don't have to cut-over the Autodiscover centrally for everyone and the integration between Exchange and Skype remains intact for the whole migration. But we don’t see any behavior in the client that indicates that the SfB client honors the TargetAddress and performs an Autodiscover on the TargetAddress domain. Source: https://blogs.technet.microsoft.com/mhass/2010/06/16/autodiscover-using-targetaddress I traced a SfB client login with Charles for a user where the mailbox was already moved. But I see just messages via EWS that indicate a quite normal connection to the old mailbox. I would expect some redirect / 302 messages that redirect to the target forest. I read that this mechanism is also used in exchange hybrid scenarios where the mailbox is hosted in O365. We already opened a premier case but this was not very helpful until now. So the idea was if somebody from the community could help. Regards, Paul
Where is Microsoft Support When you REALLY need them?
Asking legitimately. We have rolled out SfB online only with Polycom VVX phones. Everything was working fine, then one day PSTN calling stopped working. Now no PSTN calls can be connected. We have tried multiple VVX firmware versions. Tested on an Audiocodes phones and get the same result. Tested multiple networks including corporate network and local ISP. From what we can tell they switched the SIP pool on us about a week and a half ago and that's when the issue started. I have a ticket open with Microsoft (really AccountabilIT) since Nov. 25th with ZERO progress other than, "Let's help you collect some logs". I have reported the incident to the SfB Service Health page with only a generic auto reply. Is there some other Emergency number I can call to get some real help on this? What Microsoft doesn't get is that all PSTN calling is affected by this, including 911. To my knowledge nothing has changed on our end, but I would be happy to be proven wrong and just get this fixed. IMO, PSTN calling with Microsoft's cloud only solution is great solution on paper, but the lack of urgency in fixing system-wide issues like this is a deal breaker.Managing a call within SFB Android App and a Microsoft Lync Phone
Hi everyone, We're deploying for the first time SFB Edge Server in our infrastructure and We want to start using Mobility features. We use a F5 as a reverse-proxy, using the iApp for that. We manage to make it work without any problems. We can IM or make a video call within a SFB Android App, and someone in our local network. Works flawless. In our office we also have Ms Lync Phones that work flawless with SFB. The problem starts when we want to make a call within a user using SFB Android App and a user using a Lync phone in our office. We start the call, the destination phone rings, but when we answer the call, we cant hear anything and then the call ends. When the call is answer, we see traffic from the smartphone using SFB Android App trying to reach the internal ip address of the Ms Lync Phone. And there is when I'm lost. If I'm on the street using a 4G connection, and I make a call to a coworker and he answer it with his IP Phone, there's no way that my smartphone can reach the internal ip address of the ip phone. Am I missing any configuration? I think that traffic must flow trow the edge server and the edge server deliver the audio to the ip phone or something like that. Thanks in advance!
