Office 365 Migration  - Internal Outlook clients are pointing to On-premise exchange server

The migration was completed successfully, all the MX and auto-discover records are set to office 365 in our DNS portal, We tested that the Outlook clients are connecting from outside the organization are able to auto-discover the mailbox settings and able to connect to their Office365 mailbox.

Now the problem started, when the on-premise users are trying configure their outlook client, it is routing to their On-premise exchange server.

What to do ? just two steps to go , to make sure your on-premise clients connect to their Office 365 mailbox.


  1. Create a CName record for Auto Discover in your internal DNS pointing to the office 365 auto discovery server created in your Public DNS portal.
                                                         Or
    From outside your on-premise network ping autodiscover.yourdomain.com ( Note: Yourdomain.com should be replaced with your organization namespace), note down the IP address it is pointing , then come back to your local DNS and create a A record pointing to the IP which you noted down. (autodiscover.yourdomain.com should point to the IP which was resolved during ping operation from outside network).
  2. Once one of the above record is created in your network, try to ping from your internal network and check if it is pointing to Outlook.com autodiscover server.
  3. Now you need to make your AutoDiscoverServiceInternalURI to null on your CAS server, use below command to make it null.

    Set-ClientAccessServer –Identity “your CAS servername” –AutoDiscoverServiceInternalUri $NULL
Noe go back and try creating the outlook profile again , now it should discover the Office365 mailbox server settings with out any issues.
                       Azure Active Directory Sync - Creation of new objects

Hey... Directory sync was implemented to Office 365 and you see everything is synced to your Office 365 tenant.

Now , you got a doubt whats next, how to manage and create the objects ? No worry its simple. :-)

Do it in your Active Directory and it will sync to your Office 365 tenant.


  • New User : If you want to create a new mailbox for your new employee, the first create a user account for the new employee in your active directory, it will get synced to your office 365 and once it is synced you can assign Mailbox license to this user and a new mailbox will get provisioned in Exchange Admin Center for this new user.


  • New Contact: Now you want to create a new contact in for mail contact purpose, no problem create a new SMTP contact in active Directory and it will sync to your contact list in Exchange Admin center.


  • New Group : Now be little careful in understanding this, their are 2 groups, Security group and Distribution group.
    Security Group: Security groups are for assigning permissions and these are not mail enabled. So you can create a security group in AD and it will be synced to your Office365.
    Distribution Group: If you don't have a exchange server in your On-premise and you want to create a distribution group in you AD and would like to sync it to office 365 their are few additional attributes you need to create for the Distribution group to make sure the group will sync to office 365.
    Please follow below article what to be consider to create a distribution group in AD and get that synced to Office365
    http://prakash-nimmala.blogspot.in/2014/10/distribution-groups-are-not-syncing.html

                                     Office 365 - Distribution groups are not Syncing

Recently we have a Office 365 migration, where we implemented directory synchronization where we noticed that Distribution Groups created with in Active Directory are not syncing to office 365.

Finally we got a solution, if we create a distribution group with in the Exchange all the required attributes like Proxy Address, Display name , Mail etc are getting populated in the Distribution group object, however we don't want to use exchange because we are going to decommission the exchange server in future. The distribution group  created in Active Directory with out the involvement of exchange Or organization which don't have exchange servers will not populate these attributes in newly created distribution group.

So what are the attributes we need to look for ? Let us see below :

Name, DisplayName, ProxyAddress, Mail.

Yes , make sure the distribution group have following attributes , then your Distribution group will sync to Office 365 with out any issues, Let us see about these attributes and how to modify the Distribution group.

ProxyAddress: This attribute need to have to be in the format SMTP:newgroup@testdomain.com
DisplayName: This attribute should contain the name what you want to be appear.
Name: This is like an alias, so please take the first of of your email address before @ sign. ex: newgroup
Mail: This is the email address that you want to assign to the new group newgroup@testdomain.com

You can use the ADSIedit or also you can use the Attribute editor within the property of Distribution group for this purpose.

Have a good day , hope this save your time of further research.
                                  Office 365 User Password - Never Expire


This applies to Office 365 Enterprise or Office 365 Midsize organization.

Let us see how can we set a office365 user account password to never expire, Firstly we need to connect to our office 365 Tenant account:
  1. Open Azure power shell, run as administrator.
  2. Type the below command to import the MSOnline module.
     Import-Module MSOnline
  3. Type the below command and it will prompt for your Office365 credentials. Enter the credentials once it is prompted and click Ok
    $O365Cred = Get-Credential
  4. Now type the below command to initiate a PSSesssion to your Office 365 tenant account
    $O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
  5. Now enter the below 2 command in the power shell.
Import-PSSession $O365Session -AllowClobber
Connect-MsolService –Credential $O365Cred

Now you can follow below commands based on your scenario,

To set the password of one user to never expire, run the following cmdlet by using the UPN or the user ID of the user:

Set-MsolUser -UserPrincipalName <user ID> -PasswordNeverExpires $true

To set the passwords to never expire for all the users in an organization, run the following cmdlet:

Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $true

To see whether a single user’s password is set to never expire, run the following cmdlet by using the user principal name (UPN) (for example, april@contoso.onmicrosoft.com) or the user ID of the user you want to check:

Get-MSOLUser -UserPrincipalName <user ID> | Select PasswordNeverExpires

To see the "Password never expires" setting for all users, run the following cmdlet:

Get-MSOLUser | Select UserPrincipalName, PasswordNeverExpires