Adnan Rafique is a Collaboration Architect for Microsoft Exchange and Office 365. He is a subject matter expert in this area since the days of Exchange Server 2007.
He reached out to me to record an interview on Office 365, the impact of cloud technologies to the daily operations of IT administrators, and the requirement for life-long learning.
Here is the recording, available on Adnan's YouTube Channel. Enjoy.
Video-Link: https://go.granikos.eu/iMentorCloudFeb2020
A future interview will cover Microsoft Teams and how it helps to transform the way your work.
If you want to share free and busy details between two Exchange organizations, you usually use the Microsoft Federation Gateway. Sometimes this is not possible, e.g., for compliance reasons, or other business reasons. But there exists a way to do this, even without an Active Directory trust between two organizations.
Let us say we have two Exchange organizations: contoso.com and adatum.com.
The prerequisites are:
I will use user account freebusy in this example.
Execute the following in contoso.com Exchange organization using Exchange Management Shell:
$TargetSmtpDomain = 'adatum.com' $TargetDomainAccount = 'adatum.com\freebusy' Add-AvailabilityAddressSpace - Forest $TArgetSmtpDomain -AccessMethod OrgWideFB -Credentials (Get-Credentials -User $TargetDomainAccount) Set-AvailabilityConfig -OrgWideAccount $TargetDomainAccount.Split('\')[1]
Execute the following in adatum.com Exchange organization using Exchange Management Shell:
$TargetSmtpDomain = 'contoso.com' $TargetDomainAccount = 'contoso.com\freebusy' Add-AvailabilityAddressSpace - Forest $TargetSmtpDomain -AccessMethod OrgWideFB -Credentials (Get-Credentials -User $TargetDomainAccount) Set-AvailabilityConfig -OrgWideAccount $TargetDomainAccount.Split('\')[1]
Exchange Server in the source organization must be able to resolve the recipient address for requesting free/busy information from the target organization. Exchange Server can determine a target address accurately when you create the recipient object as a contact in the source Exchange organization.
For this example, you create contact objects in adatum.com for all user in contoso.com and vice versa. You can use GalSync or any other identity management (IDM) software that can handle object synchronization.
When using Exchange Server 2013, or 2016, you may run into a problem.
The HttpProxy log of the requesting Exchange Server log will state that AutoDdiscover failed for generic mailbox 01B62C6D-4324-448f-9884-5FEC6D18A7E2@contoso.com (or adatum.com).
HttpProxy log excerpt:
2019-07-26T07:19:24.649Z,2827102f-75b1-4ecb-ae6c-36b075bb8e93,15,1,1779,2,,Autodiscover,autodiscover.contoso.com,/autodiscover/autodiscover.xml,,Basic,true,CONTOSO\freebusy,,MailboxGuid~01b62c6d-4324-448f-9884-5fec6d18a7e2,ASAutoDiscover/CrossForest/EmailDomain//15.01.1779.002,172.16.0.20,CONTOSO-EX1,404,,MailboxGuidWithDomainNotFound,POST,,,,,AnchorMailboxHeader-MailboxGuidWithDomain-NoUser,,,,381,,,,0,,,0,1;0;,1,,0,1,,0,4,0,,,,,,,,,0,3,0,,3,,3,3,,,,BeginRequest=2019-07-26T07:19:24.646Z;CorrelationID=<empty>;ProxyState-Run=None;AccountForestGuard_contoso.com=1;AccountForestGuard_contoso.com=1;ProxyState-Complete=CalculateBackEnd;SharedCacheGuard=0;EndRequest=2019-07-26T07:19:24.649Z;I32:ADS.C[CONTOSO-DC1]=2;F:ADS.AL[CONTOSO-DC1]=0.8201787,HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: Cannot find mailbox 01b62c6d-4324-448f-9884-5fec6d18a7e2 with domain contoso.com. at Microsoft.Exchange.HttpProxy.AnchorMailbox.CheckForNullAndThrowIfApplicable[T](T ret) at Microsoft.Exchange.HttpProxy
If DNS is used to resolve the AutoDiscover endpoint of the target Exchange organization, the source Exchange organization queries AutoDiscover information for a mailbox with that uid. SCP-based AutoDiscover lookup does not use this dedicated uid-based email address.
To solve this issue, you add the required SMTP address found in the HttpProxy log to one user mailbox in the target organization.
In the contoso.com organization:
Set-Mailbox -Identity 'someuser@contoso.com' -EmailAddresses @{add='01B62C6D-4324-448f-9884-5FEC6D18A7E2@contoso.com'}
In the adatum.com organization:
Set-Mailbox -Identity 'someuser@adatum.com' -EmailAddresses @{add='01B62C6D-4324-448f-9884-5FEC6D18A7E2@adatum.com'}
When you configure an Outlook profile to use Cached Mode the client software uses a special address book to resolve email addresses and other information. This address book is named Offline Address Book (OAB) and is built and provided by the Exchange Organisation hosting the mailbox. The client downloads OAB changes when Outlook starts and checks for further OAB changes in intervals.
OAB provides address resolver capabilities when there is no network connection to Exchange Server or a domain controller available. In addition to resolver capabilities, the OAB contains other important information, e.g., send-as permissions and information regarding public folders.
For security reasons it might be necessary to disallow the download of the Offline Address Book by an Outlook Client. In this case, you control the download functionality with the Windows System Registry. You can disable the OAB download using the following registry key:
Path: HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\Cached Mode Value type: REG_DWORD Value name: DownloadOAB Value: 0 to not download the OAB
Replace <version> with the appropriate Office version number.
With a deactivated OAB download name resolution in Outlook Cached Mode requires network access to an Exchange Server
Enjoy Exchange Server.
Auf dem aOS Aachen September 2018 Event hat Luise Freese die Vorträge in ihren bekannten Sketchnotes festgehalten.
Hier sind ihr Sktechnotes zu meinen beiden Sessions.
Wer die Ignite 2018 besucht, kann Luise Freese dort treffen. Sie ist Chief Community Sketcher der Konferenz in Orlando.
A custom domain can only be registered once across all available Office 365 instances (Global, Germany, and China). In order for a registered domain to be used in a new tenant, the registered domain must be removed from the old tenant.
The following text assumes that you have already migrated or backed up all user data. Otherwise, the steps described will result in the immediate deletion of data or a release for deletion within Office 365. If the domain to be deleted is the tenant's default domain, accounts for guest users (user_remotedomain#EXT#mydomain.com) stored in Azure AD also use that domain name. using that domain. These accounts must be removed as well.
If the old tenant synchronizes with Azure AD Connect this configuration must be removed first. The domain to be deleted must not be used by any user or group object in Azure AD. Your options are:
Use PowerShell to verify if there are still objects using the domain name to be deleted..
# Install the Office 365 PowerShell module Install-Module MSOnline # Import the module, if it's installed already Import-Module MSOnline # Connect to Office 365 using a global admin account w/o MFA Connect-Msolservice # domain name $Domain = 'granikoslabs.de' $Filter = "*@$Domain" # List all Office 365 users with a UPN using the domain name Get-MsolUser -DomainName $Domain | FL UserPrincipalName # List all Office 365 users with a proxy address using the domain name Get-MsolUser | Where-Object {$_.ProxyAddresses -like $Filter} # List all Office 365 groups with a proxy address using the domain name Get-MsolGroup | Where-Object {$_.ProxyAddresses -like $Filter} # List all Office 365 groups with an email address using the domain name Get-MsolGroup | Where-Object {$_.EmailAddress -like $Filter}
If you get any results from the list queries you must clean up the objects first. Without modifying the objects you cannot remove the custom domain from Office 365.
If the queries did not return any result you are safe to remove the custom domain from the old tenant.
# Domain removal Remove-MsolDomain -DomainName $Domain -Force
After the final removal of the custom domain
After deleting the custom domain from the old tenant, the domain can be added to a new tenant relatively quickly in other Office 365 instances.
Enjoy Office 365!