MOC uses this address, plus a specific per-query port number to attempt the connection to an OCS Server for the target domain. Synthetic A record queries look for an A record that has the IP address of an OCS Server. Together the SRV and associated A record specify the IP address and port number that MOC uses to connect to an OCS Server for the target domain. Synthetic SRV records search for an SRV resource record that in turn points to the A record. There are two types of synthetic DNS queries that are used by MOC: synthetic SRV record queries and synthetic A record queries. To simplify the user experience, and reduce support costs, you should implement DNS-based auto-discovery. In that case, MOC used the manually entered information and does not attempt auto-discovery. If no query is successful MOC can log the user in.Īs an alternative to auto-discovery, of course, the user can enter the server details manually. If a query is successful, then the information in that query is used to find the user’s OCS server.
Having discovered the target domain, MOC’s auto-discovery then synthesises a series of DNS queries, and sends these to the local DNS server – one at a time until a successful query result is obtained (or not). # gets the domain from the AOR and displays result The user inputs his SIP URI (minus the “SIP:” scheme id, as well as AD credentials (in most cases these are the same, a UPN such as ).įor fun, here’s a PowerShell script to get and display the target domain from the AOR The SIP URI has to obtained through user input. This could be something like From the AOR, MOC needs to determine a target domain (the spec just calls this domain). Using auto-discovery, MOC first obtains what the specificatin calls the Address-of-Record, aka the SIP URI. The OCS mechanism is simple and easy, while the Exchange service is more complex. Note that this mechanism is used by a MOC client to find an OCS server, and is different from Exchange’s auto-discovery service that enables Outlook to find an Exchange server. I’ve been reading the formal published specificatin in the absence of bed-time cocoa. Auto-discovery is based on MOC’s use of DNS resource records to obtain the necessary information. (I've already told them they need to learn if they are going 365.It seems to be a day for writing about auto-discovery, the process whereby an application, in this case Microsoft Office Communicator (MOC), can use a limited amount of information to automatically discover the users’s OCS Server. It wouldn't be an issue at all for me, but this isn't a group with any powershell experience. ADSI edit and Powershell isn't going to be a good solution for Not an issue, I run a hybrid exchange, but in their case they won't have In place without running the Hybrid Configuration Wizard, you stillĬannot manage most of the recipient tasks from the cloud. In addition, even if you have directory synchronization This is notĭue to the hybrid configuration, but it occurs because of directory Synchronized from on-premises, most of the attributes cannot be managedįrom Exchange Online and must be managed from on-premises. When directory synchronization is enabled for a tenant and a user is If anyone is currently using it and wants to provide feedback on how it works for you, that would be appreciated.
I may have to set up a trial and test that out.
There's also the option of Windows Server Essentials Experience role managing the 365 side. That wouldn't be the end of the world, but I'm curious as to if they can improve on that a bit. One option here is to be cloud only and they will need to manually create accounts the way they do things now with G Suite. Ultimate goal is simple account provisioning/password sync without the dreaded, you can't modify this because it's synced from an on premise account issues with Exchange online.
Has anyone heard differently in this regard? I really don't want to introduce an Exchange hybrid server back into this particular environment.
When last I checked, and this still seems to be the case, if you want to sync your on prem AD to Azure AD for your 365 accounts, you still need an Exchange hybrid server to be officially supported. This scenario falls in between those implementations.
I've implemented full cloud only 365 scenarios where it's not tied to an on prem AD at all as well. I'm a full blown 365/Azure AD connect/ADFS/Exchange Hybrid setup however which is vastly different from what they want to do. The admin there asked me about it as I'm well versed on the admin side for 365. Have a company looking to migrate from G Suite to 365.