We recently came across an issue where a customer could not sign-in to a Microsoft Surface Hub.
There’s a great article here: https://ucsorted.com/2015/08/31/understanding-user-mapping-in-a-skype-for-business-resource-forest/ explaining how a Resource Forest model works.
When you enable a SfB user, the proxyAddresses attribute is populated with the users SIP address in the format SIP:[email protected]. In a Resource Forest model this is populated on the disabled user object in the Resource Forest. Usually the attribute flow is one way from the User Forest to the Resource Forest so the SIP: value never populates the proxyAddresses attribute in the User Forest.
To resolve we added the correct SIP: value to proxyAddresses on the Surface Hubs AD account in the User Forest.
Technical Architect at Symity
Hi Chris,
have you created a LinkedRoom mailbox in this scenario?
Hello, no I haven’t although it could be a similar problem where the ProxyAddresses in the User Forest require configuring.
So how did you create the room mailbox for that account?
Room Mailbox was in Office 365, the Resource Forest only hosted Skype for Business. Architecture was:
User Forest – Contained Surface Hub User Account
Exchange Online – Azure AD Connect sync from User Forest, user enabled as a Room Mailbox
Skype for Business Forest – Microsoft Identity Manager sync from User Forest, user enabled as a SfB Meeting Room