Officedocs-skypeforbusiness: Decommissioning the on-premises servers?

[NavishkarSadheo]

Hi

Can you perhaps add some information about decommissioning the on-premise Skype for Business servers?

Do I just uninstall?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 3ce37c7f-6f13-8442-bfdb-47065a7339b3
• Version Independent ID: 9a2b5082-369d-7c04-4fa8-81c1440ea119
• Content: Disable hybrid to complete migration to the cloud - Skype for Business Hybrid
• Content Source: Skype/SfbHybrid/hybrid/cloud-consolidation-disabling-hybrid.md
• Product: skype-for-business-itpro
• GitHub Login: @CarolynRowe
• Microsoft Alias: crowe

[scanum]

@NavishkarSadheo Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

[tkalaj]

I'd like have this information as well. Any update to share on this?

[K4S1]

@scanum Could you please provide an time EST. On when the investigation are done and ready.
For us to see how to prober decommission the LFE.
I would guess just to uninstall it. but I'm afraid the uninstallation will remove properties from AD users, that will be synced to Microsoft and destroy a setup. and have not been able to find any other documentation that describe this correctly.
If I need to find the documentation another place, please advice me :-)

Thanks and a great day.

[J-Fedor]

I don't think you'd be able to decommission a front-end server with "active" user accounts. I had previously followed the instructions in https://docs.microsoft.com/en-us/archive/blogs/fasttracktips/decommissioning-skypelync-on-premises which is for post-migration to Skype Online. No side-effects for us, but obviously goes against the first "Important" box at the top of this page. The attributes for Line URI make no sense to be managed on-prem when you're assigning numbers in Teams/365. But all our servers were decommissioned properly without the users associated with a front-end pool. Perhaps the team needs to reach out to the author "Daniel Seleri" and figure out what's best for everyone going forward, since this doc seems to fall far short of the other guidance provided. Thanks.

[CarolynRowe]

Hello, I'm not sure which doc you are referring to when you write "this doc seems to fall short." Can you clarify? That will help me follow up with the right product team members. Thank you.

[J-Fedor]

"this doc" - the page I'm commenting on. That's what has fallen short by comparison the Seleri doc

[bjwhalen]

this doc "https://docs.microsoft.com/en-us/archive/blogs/fasttracktips/decommissioning-skypelync-on-premises " is incorrect and needs to be fixed. Onprem attributes should not be removed. users may lose service if in various cases.

[J-Fedor]

OK, so how are we decommissioning on-prem servers while servers are still enabled on the servers? Seems to be a gap missing. Just yank and pretend they were never there? Seems like leaving a debris field behind that wasn't fully planned.

[bjwhalen]

You must only do the decomm after you have moved all onprem users to online using move-csuser. Once you've done that, they are homed online and not serviced by onprem. there is no gap. Just wipe the server.

[J-Fedor]

You don't even check for any on-prem users in your process.
You don't clean up conference directories
You don't provide instructions on server removal
Etc.

There's a lot of things done that should be done that is on that other doc that this doc doesn't even hint at needing to be completed.

Based on the amount of details & effort involved, the one you don't like provided far more guidance to how to do something than the one that is "current". It really needs to be enhanced to be useful.

And some clarity and why there'd be problems clearing on-prem attributes would be beneficial vs being "Oz"-like. The phone and SIP addresses are all up in 365 afterwards still, not reliant on-prem, so what/why would services be lost? Seems a bit vague and based on experience thus far, we haven't had the situation where it "could" cause loss of service. And even the other doc says to pilot and verify. Seems better to have a cleaner AD than on-prem attributes being managed in an unfriendly manner that don't have a bearing on the cloud service.

[scanum]

@K4S1 Thank you for submitting feedback. We understand that this issue has been resolved.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.