Decommission Skype 2015 On-Prem servers
I want to decommission our Skype On-Prem (2015) servers and cleanup AD from the RTC delegations and groups (RTC* and CS*). I've been following the guide: https://learn.microsoft.com/en-us/skypeforbusiness/hybrid/decommission-remove-on-prem However, when doing step 1 of "Prepare to remove the Skype for Business deployment" and run the commands, the command Get-CsAudioTestServiceApplication returns an object. In step 2 there is no corresponding Remove-cmdlet, so we tried disabling it with the Set-cmdlet. Moving on to "Remove your on-premises Skype for Business deployment", when getting to step 3 I run "Publish-CsTopology -FinalizeUninstall" but gets the following error. Publish-CsTopology : Command execution failed: Cannot publish topology changes. Users or contacts are still homed on a pool that would be deleted. Move or remove the users or contacts before continuing. At line:1 char:1 + Publish-CsTopology -FinalizeUninstall + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [Publish-CsTopology], Inva lidOperationException + FullyQualifiedErrorId : ProcessingFailed,Microsoft.Rtc.Management.Deploy ment.PublishTopologyCmdlet Running the command generates a html file with the result, where the same error can be found and the following suggestion: "UserPoolInUseResolution: Consult your Skype for Business Server documentation to learn how to move or disable objects still homed on the pool. To find those objects, execute the following cmdLets: Get-CsUser, Get-CsExUmContact, Get-CsCommonAreaPhone, Get-CsAnalogDevice, Get-CsRgsWorkflow, Get-CsDialInConferencingAccessNumber, Get-CsAudioTestServiceApplication, Get-CsTrustedApplicationEndpoint, Get-CsPersistentChatEndpoint." So I'm guessing we need to get rid of that Audio Test Service Application, anyone got any ideas how to do that? I can't find anything for it in the GUI either. The main objective is to clean up any remnents in AD, the entire Skype environment will be removed and all servers decommissioned. I'm guessing that the Disable-CsAdDomain and Disable-CsAdForest cmdlets does this somewhat. Is the above steps a requirement to be able to run these cmdlets, or would this be a viable option?
Teams meeting room stuck on signing in
Our Teams meeting room is stuck on signing in on SfB. Somehow the newly created Teams Room (Logitech Tap) the UPN, SIP and email are the same keeps on showing this message on the tap: The connectivity health gives the following information: I've tried a couple of things (changing UPN/Mail/SIP and changing from SfB only to Microsoft Teams) but it still doesn't work. The earlier created Teams Meeting rooms are still functioning.
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?
Skype for Business video is mirrored
When we hosted a meeting at SfB, my screen is mirrored. Others see it correctly. The problem is I connected my screen to a LED screen, when I locked my screen for all. All audiences in this meeting will see the mirrored screen. It is not beautiful feedback from my customer. You can see the attached image. The text should be Prime Minister's Office Any solution?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.
