User Profile
ryan-whitehelm
Brass Contributor
Joined 7 years ago
User Widgets
Recent Discussions
Re: Microsoft Teams Rooms systems - join button for known external services
Ilya Bukshteyn Very happy with what was announced at Ignite on this front, can't wait to start testing it. Quick question, in the blog at https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/What-s-New-in-Microsoft-Teams-Ignite-2019/ba-p/937025#meetings it mentions "This capability will be supported on a new generation of meeting room devices with embedded web technology." I'm in the middle of a rollout of Logitech Tap with Intel NUC MTR systems. Are we likely to see this functionality as part of the regular upgrade cycle, or does "a new generation" mean we'd need new hardware for the new features?3.5KViews0likes2CommentsMicrosoft Teams Rooms systems - join button for known external services
I've spent a couple of weeks down the rabbit hole of video calls between us an other organisations. We want to be as flexible as possible, allowing externals to join our conferences from their endpoints, and supporting our users joining external conferences from our MTRs. We have set up CVI trials with Pexip, BlueJeans and Polycom. All three address the external dialing in to our call pretty well, but we're sometimes finding a bit of a tug of war over "no we'll host, that way we know it'll work in our meeting rooms. You join OUR meeting". When both orgs want to host, it's less clear. Webex and Zoom both have well-known SfB/Lync gateways that may be included in the meeting invite. Zoom it's MeetingID@lync.zoom.us. Webex it's ConfID.TenantID@lync.webex.com. Both only work if the right bits are switched on in the respective Zoom/Webex tenancy, but if they are the address in SfB/Lync format should be included in the meeting invite. I've been practicing with users identifying these invites and dialing them in our MTR rooms. That works, but it's pretty manual. I saw in this thread https://techcommunity.microsoft.com/t5/Skype-for-Business-IT-Pro/SRS-V2-externally-hosted-meetings/m-p/102102#M2777 that there's code in the Teams app on the MTR that parses meeting invites and looks for https://teams.microsoft.com/l/meetup-join/ URLs to turn in to Join buttons. It would be amazing if that same process came across an anything@lync.zoom.us or anything@lync.webex.com address in the call it added a Join button to the console which dialed that SIP address. Ilya Bukshteyn I doubt it's a high priority for anyone, but it would look really slick if it worked and would go some way to me being able to sell these MTR rooms to management as good for more than just internal meetings.3.8KViews0likes4CommentsRe: Any way to make Private meetings not show the name on Teams Rooms Phones?
On the Exchange mailbox, Set-CalendarProcessing is the command that controls how meeting room mailboxes handle invites. I think the one you're looking for is Set-CalendarProcessing -Identity room@domain.com -AutomateProcessing AutoAccept -RemovePrivateProperty $false I think from the doco that will make it honour the Private flag.8.3KViews0likes2CommentsRe: Request to Join Private Group
We are seeing the same behaviour on a bunch of new SharePoint sites created as part of new Office 365 Groups. I understand that from SharePoint's perspective, this is behaving as designed. User is trying to access a SharePoint site they don't have permission to, SharePoint is generating an access request, when it's approved they're getting added to the SharePoint group, not the Office 365 Group. I follow the logic, but it's confusing for end users. I don't want to have to explain to a collection of accountants and actuaries the difference between SharePoint groups and O365 Groups. The whole concept of Unified Groups/O365 Groups is that you don't grant people access to the individual components, you add them to the O365 Group and everything flows from there. If I go to the Site or Document Library there are the little circles in the top right corner showing who is a current member of the group, and if you click that and Add Member, the person gets added to the Office 365 Group. That's the sort of behaviour I expect on O365-Group-connected SharePoint Sites. My problem is when one user wants access to some files, and another user emails or IMs them the link to the sharepoint site. If User1 is already in the Group, all works, they get the files. If User1 isn't in the group then they get a page that invites them to generate a *SharePoint* access request, which goes to the O365 Group Owner. When it's approved they get access to the SharePoint site, but not the larger O356 Group. The workflow by users is sensible. I can also understand why SharePoint currently works the way it does, but I think that behaviour should be changed on Group-connected sites. Explaining to users that when they see that prompt they should close Edge and go to *Outlook* or OWA and search for the Group there to request access... people aren't going to do that. It's counter-intuitive. And when they do it the "wrong" way and request access via the form SharePoint puts under their noses, and the O365 Group owner approves, they *get the files they want*, so as far as they're concerned the "wrong" way works fine. It's very hard to train people to do something totally different in that situation. Anyway, that's my take on it. Rant over =)12KViews1like0Comments
Recent Blog Articles
No content to show