Forum Discussion
New Skype4B Hybrid Setup - On-Prem has no Presence for Online Users
Hi
Please can you clarify this "Just set up a new Skype4B hybrid (first time in yeeeeeeeeeeers). Attaching an on-premises pool with one set of SIP addresses to a Skype4B Online environment with another set of domains for SIP addresses."
I am assuming that your SIP domains exist in your On-Prem topology and the same ones exist in 365? If not they need to match.
Secondly, assuming that your have synced your AD to Azure AD?
One question - the cloud users where they enabled in SfB Online first? If so then this would explain your behaviour. You'll need to tell your on-prem that they existin in the cloud, by enabling them like so
Enable-CsUser -Identity "username" -SipAddress "sip: username@contoso.com" -HostingProviderProxyFqdn "sipfed.online.lync.com"
Hi, Mark.
Embarassingly, I spaced on adding the cloud SIP domains to the On-Premises topology. I added them and am crossing my fingers.
On the Online side of things, I do see the SIP domains for the on-prem environment listed under Organization domains in the Skype4B Admin Center's dashboard (along with the cloud SIP domains).
We are syncing our AD to Azure AD but the user's from the cloud SIP domain are created in the cloud and not synced from AD. The users with the On-Prem SIP domains are created in AD and synced to Azure AD.
Yes, it's very, very strange. No, it's not my fault. :) Working on trying to unify and standardize the on-prem and cloud environments which have historically been very, very separate.I have a question aout the enable-csuser command. I tried it on my account on-premises and get an error:
"enable-csuser : Cannot move user in enable operation. Use the Move user cmdlet
instead."To comment on your command, the person you run this against must only exist in the cloud. If you run this against an On-Prem user it will fail, because you're already enabled for on-prem
Sorry for the absence. Real life getting in the way of work stuff.
We have about 6,000 dirsynced accounts in the on-premises SIP domain and another 23K that exist only in the cloud and are not dirsynced in a separate SIP domain space.
We updated all the DNS entries for the cloud SIP domain (lyncdiscoverinternal, lyncdiscover, _sipinternaltls._tcp, etc.) and the cloud accounts stopped being able to sign in (or at least my test account). It looked to me like it was trying to authenticate to the on-premises domain controllers but I might be mistaken.
We removed the DNS entries so that accounts with the SIP domain for the cloud environment pointed to Skype4B Online when logging in and I was able to log in with in a cloud only account again.
Now, the cloud users and the on-premises users can see each other's presence if they are in the contact list, or if you have opened a conversation window with them at some point (regardless of whether you send an actual message).
If you just use the search feature to find a new contact, you get "Presense Unknown."
I'm not sure I understand what's going on but it's better than before.
I think my next steps are to observe what happens when I migrate on-premises users to the cloud. I can't migrate (existing) cloud users on-premises because they are not dirsynced (that's another battle for another day).
Thanks for your help and being understanding of my (very) strange setup.
Yes, as Mark says the online users are not aware of the on-prem environment and have to be enabled on-prem first, then moved to the on-prem pool and then back online. Make note that all attributes have to be successfully sync'ed between every step.
Missed this comment before I posted just a minute ago.
So, the CLOUD users will need to be enabled on-prem, moved to the on-prem pool, and then moved back online?
There's about 30,000 of them but if it works on a test group, I can gin up a PowerShell script.Hi
Yeah to do hybrid properly, you'll need to add all O365 domains to your additional domains in On-Prem topology. This of course means updating certs.
You then need to make sure that DNS is pointing towards your On-Prem for all SIP domains in 365. Otherwise federation will not work right and you'll get weird issues.
Those accounts also need to be sourced from your on-prem AD. The problem is the -SharedSIPAddressSpace parameter on the tenant, basically is responsible for this complexity as it is a tenant level setting not per SIP domain.
There is also a weird quirk in how 365 performs federation. If a SIP domain exists in your tenant it will hairpin inside the tenant the communication. It will not break out to the internet, or perform DNS SRV lookup. So if you dont configure hybrid properly for all domains, you'll get this weird behaviour. I know, i've been through this pain :s
If this is not possible, you need separate tenants.
Assuming it is, you do not need to move users back to on-prem then move them to online, although that would work. The enable command should work provided your account of course is in 365 and not on-prem already. Basically what this does is tell the On-Prem SfB that the user is part of the topology, but is hosted on SfBO. this allows internal users to route to cloud users and also vice versa.
