Tag Archives: Office 365

EWS not working in Exchange Hybrid

Deploying a hybrid Exchange environment should be a carefully planned process though you might encounter hiccups here and there unexpectedly. In a recent hybrid effort after executing the HCW for Exchange 2013 I have noticed that two tedious issues happening in the environment.

  1. Free/Busy information is not visible in Outlook Clients (any version). Scheduling Assistant throws an error saying that it cannot locate the server. Outlook Web App works just fine.
  2. Unable to create a migration batch from the EAC. It throws below error.

The ExchangeRemote endpoint settings could not be determined from the autodiscover response. No MRSProxy was found running at <FQDN of CAS server>.

I decided to have a look on the properties of EWS virtual directory for CAS servers. EWS is responsible for remote moves & free/busy information.

Enable MRS Proxy endpoint option was selected as it should be. Also I could access the EWS service from outside. So the URL is correct.

EWS (1)

When I checked the authentication section the Integrated Windows Authentication option was not enabled so I enabled same. This option allows domain joined computers to use session credentials of their respective windows logins with Outlook clients.

EWS (2)After doing iisreset on all CAS servers I noticed that Free/Busy information is now available via Outlook and I can successfully create and complete migration batches as well.

This TechNet article explains different scenarios in an Exchange Hybrid deployment which can result in such an error and worth a look if you cannot see free/busy information from one tenant to the other (Exhcnage Online Users cannot see Exchange On-Premises free/busy info and vice versa)

Outlook 2007 Clients are disconnected in Exchange Hybrid

Deploying an Exchange Hybrid setup requires lot of effort specially around DNS records. In a recent deployment I noticed that Outlook 2007 clients are in disconnected state once the Hybrid feature has been enabled for an Exchange 2013 single forest organization.

We were using a new Subject Alternative Name (SAN) Certificate from a third party CA which included AutoDiscover.domain.com record. An autodicover record is vital to share free/bust information between Exchange Online & On-premises organization, as well as clients to differentiate where there mailboxes reside.

The problem was not present in Outlook 2010/2013 clients and creating new user profiles was not an option and was not a remedy. Renewing the SSL certificate has always been troubling if we don’t do it the proper way.

Solution

I decided to take a look on autodiscover virtual directories first. To do that open Exchange PowerShell as administrator and executed below cmdlet.

Get-AutoDiscoverVirtualDirectory | fl internalurl,externalurl

The virtual directory was not pointing to correct URL. Therefore below cmdlet has been used to rectify same.

Get-AutodiscoverVirtualDirectory -server <Server Name> | Set-AutodiscoverVirtualDirectory -ExternalUrl ‘https://<Server FQDN>/Autodiscover/Autodiscover.xml’ -InternalUrl ‘https://<Server FQDN>/Autodiscover/Autodiscover.xml’

I had three MBX/CAS servers to run this cmdlet. The <Server Name> placeholder represents same. Now in IIS Manager of each MBX/CAS server, right click the MSExchangeAutoDiscoverAppPool application pool and click Recycle. This will recycle the AutoDiscover application pool.

When I checked the connectivity of Outlook 2007 clients most of them are showing connected and e-mails were downloading without any issue. For those clients that didn’t respond we had to reconfigure Outlook profiles but it was quite a few.

Recommendation

I’m not really comfortable with Outlook 2007, specially if it involves Office 365. If you intend to use Outlook 2007 with this kind of a setup I strongly suggest that you update to the latest service pack or if possible update it to Outlook 2010 at minimum. Service Packs play a vital role and in this case none of those Outlook clients were patched.

Office 365 woes | Password Sync doesn’t synchronize with Azure AD Connect

Microsoft has retired DirSync tool and introduced one tool to synchronize your on-premises identities to Microsoft Azure Active Directory. This tool “Azure AD Connect” can be used in both Office 365 only & Azure AD without O365 scenarios to extend your local AD to the cloud. One of the key advantages is the ability to synchronize the password hash of local AD account with Azure AD where the users will have a single identity & password rather than two different sets of credentials. This is a hash of the password hash stored in your local AD not clear text password. This feature is heavily used in Office 365 deployments to provide SSO (Single/Same Sign On) capabilities to the users to provide single consolidated identity.

I’m working on an Exchange 2013 Hybrid setup these days where one of the prerequisites is to setup Directory Synchronization. We have identified the password hash sync is also required in this situation. When I completed the Azure AD Connect setup wizard I got below error at first. If you are unfamiliar with configuring AAD connect you can refer here.

Now surprisingly I cannot connect to Azure AD via PowerShell and got the same error. My credentials were correct and I decided to check that with my laptop (different ISP) and it was a success. Surprisingly the local ISP has some connectivity issues with Office 365 IP ranges and frequent timeouts were evident and then we changed the network path to a different ISP to resolve the issue.

Since the wizard was completed and no accounts were synced, I decided to go for a manual force sync with PowerShell. Notice the path for DirSync binaries; it hasn’t been changed in AAD Connect as well. The option Initial will do a full synchronization where the option delta will do a delta sync only.

C:\Program Files\Microsoft Azure AD Sync\Bin> .\DirectorySyncClientCmd.exe Initial

All the user accounts were properly synced this time but when I tried to login to Office 365 using an AD account it always says that the password is incorrect.

Investigation

When I tried to review the existing configuration for Azure AD connect I noticed that it reports the password sync as disabled. Uninstalling the tool, installing again and performing couple of full sync were useless and still I was getting the same issue when I’m trying to login.

  1. Verified password sync is disabled via using PowerShell

    Following cmdlets have been used to verify above and I noticed password sync was in fact disabled although I checked the option in Azure AD connect setup.

    Import-Module ADSync

    Get-ADSyncAADPasswordSyncConfiguration -SourceConnector <‘LOCAL DOMAIN NAME>

  2. Enabled password sync via PowerShell

    Set-ADSyncAADPasswordSyncConfiguration -SourceConnector <‘LOCAL DOMAIN NAME> -TargetConnector <‘xxxxxxx.onmicrosoft.com – AAD’> -Enable $true

After executing above cmdlets and another full synchronization I noticed below error has been logged in Directory Synchronization event log, still with no luck with passwords.

In the Synchronization Service Manager (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe) displays status of “stopped-extension-dll-exception” for operations on the Microsoft Azure Active Directory Connector.

Solution

  1. The “stopped-extension-dll-exception” error was due to the fact that password policy of Azure AD Sync account, set to expire after a certain number of days. This account is created automatically once you run the Azure AD Connect wizard.

    To set the password to never expire following cmdlets were used.

    PS C:\> Connect-MsolService

    Provide your O365 admin credentials to connect to Azure AD service.

    PS C:\> Set-MsolUser -UserPrincipalName <Sync Account UPN> -PasswordNeverExpires $true

  2. Make sure the sync account is a global administrator in your office 365 tenant. In my case it was not and I have assign the user role Global Administrator to that account. You can refer the original Microsoft Office 365 support article on how to do that here.
  3. To overcome the “Password Synchronization has not been activated for this company” error is logged in Event Viewer I executed below cmdlet again in PowerShell.

Set-ADSyncAADPasswordSyncState -ConnectorName < ‘xxxxxxx.onmicrosoft.com – AAD’> -Enable $True

Morale of the Story

When I ran the Azure AD Connect wizard for the first time I selected Start the synchronization process ASAP option as below. Due to the issues I have faced with internet connectivity it wasn’t much of a success.

Also I didn’t select the Use an existing service account option during installation. By default, Azure AD Connect will create a local service account for the synchronization services to use in that case the account that wasn’t a global admin. The user role (which should be global admin), password expiration policy & password is unknown in this automatically created account. Therefore I highly recommend to use an existing global administrator account in your O365 tenant to overcome this.

Also always use the Customize option where you have control over additional configuration options such as above service account while setting up Azure AD Connect.

Configuring Azure AD Connect Preview

Microsoft has introduced a new tool to synchronize your on-premise active directory with Azure AD. Previously  DirSync & AAD Sync were the tools used to achieve this. From my experience DirSync was mainly focused on Office 365 deployments which later neede much more improvements when Azure came in to GA.

From now on there will not be new releases of above tools and the new Azure AD Connect will be production ready within the next 3 months as per Microsoft. This tool will unify the capabilities of DirSync & AAD sync providing a single UI capable of much more.

All the new features introduced with AAD Sync are included in the Azure AD connect as well.

  • Multi-forest synchronization is possible for Active Directory and Exchange
  • Password write back from Azure AD to on-premise Active Directory

Other features like OU & Attribute based filtering from DirSync remain same. Let’s see how we set up this little beast.

  1. Download & Install AAD Connect tool from here.
  2. Open the Azure AD Connect tool in your desktop and proceed with the license agreement.AAD Connect 1
  3. You will be prompted to install any per-requisites that are needed. These include Microsoft .NET Framework 3.5, MS Online Services Sign in Assistant, Windows Azure Active Directory Module for Windows PowerShell & Azure AD Sync Engine. It’s best that you install first three prior installation to avoid issues.AAD Connect 2 AAD Connect 3
  4. Provide your Azure AD Credentials in the next screen. Note that if you are using Office 365 this would be your global administrator credentials. If you are using Azure AD standalone I would suggest that you create a separate user called DirSync which has global administrator rights for your Azure AD.AAD Connect 4
  5. You can either select Use Express Settings or Customize depending on your requirement. If you are using this tool for Same-Sign-On you can safely use Express settings. Here we are proceeding with Customize option.AAD Connect 5
  6. If you only want Same-Sign-On (Same user name & password as in on-premise AD but will be prompted for credentials) choose Password Sync. If you have implemented ADFS for Single-Sign-On (Users will be authenticated from local AD and no need to enter credentials once logged into the system using domain credentials) Select Single Sign On.AAD Connect 6
  7. Now you have to enter the credentials for your local AD. Note that you can add multiple directories here.AAD Connect 7 AAD Connect 8
  8. If you are planning an Exchange Hybrid Deployment where some user mail boxes will reside on-premise and some are in Office 365 select Exchange Hybrid Deployment. Selecting Password write-back will enable to replicate the password from Azure AD to local AD and  will allow users to self-reset their password if they are assigned Azure AD Premium licenses.AAD Connect 9
  9. The next screen is vital if you are syncing multi-forest environment.  But since I don’t have that I’m proceeding with the first option.AAD Connect 10
  10. You can configure the object mapping in the next screen. As my on-premise UPN & Cloud UPN are same I’m leaving this as default.AAD Connect 11
  11. If you want to configure filtering uncheck the Initial Synchronization check box. You can configure filtering by launching the FIM client  later. This tool is available at  C:\Program Files\Microsoft Azure Active Directory Sync\UIShell\miisclient.exeAAD Connect 12AAD Connect 13
  12. If synchronization is successful you will see the user account from your local AD in your Azure AD. Just in case if you cancel the wizard prior step 11 when you run the tool next time you can resume from where you have left. AAD Connect 14 AAD Connect 15 AAD Connect 16

One important thing. This tool is not still GA so if you are deploying this to production use at your own risk or wait few days till this becomes GA.