Experience Exchange Sever

April 10, 2017

Case study for Office 365 migration – Part2

Filed under: Uncategorized — vijayarelangovan @ 9:00 am

So, in my previous post i have discussed about the existing setup and the challenges to address the problem.

Here, i’m going to discuss about the proposed architecture and how it is going to address the challenges.

new architecture

  • Before starting the new setup, the mailbox that was created for ABC users on UK.XYZ domains are removed.  The synchronizations between mailboxes are removed.
    • Reason : This is to make sure there is no duplicate user mailbox residing on either side of the forest.
  • UK.XYZ exchange and ABC exchange connected to each other (Quest migration manager).
    • Reason : The mailboxes from UK.XYZ to ABC exchange to be migrated and it needs to be associated with the AD Account associated with each users AD account.
  • AAD Connect is installed on ABC.COM to synchronize to the AD Azure.
    • Reason : This is to make sure only ABC should be the primary domain, eventually the other domains acts as a resource domain for other applications and slowly decommissioned
  • New domain called @azuredomain.com and used as upn for both ABC and xyz.com domains
    • Reason : This is to have a common authentication.  So users can use this as a domain to authenticate themselves to office 365
  • Federation trust and connectors on both the uk.xyz.com and abc.com exchange servers
    • Reason : When users are connected in their respective domains, they should be able to resolve other users name, share calendar and route autodiscovery service seamlessly
  • New exchange CAS server installed in uk.xyz.com and given exception to the CAS Array and a third party certificate installed which just one domain
    • Reason : This is to make sure, this server act as a EWS/MRS endpoint.  The users don’t connect to this server by giving exception in the CAS array.
  • Cloud identity management introduced to make sure it is does the authentication
    • Reason : No separate architecture required for ADFS.  This also enables the customer to use more cloud based solutions such as Box.
  • Remote mailbox has been created for every user mailbox which are migrated from uk.xyz to abc exchange server
    • Reason : When user connects to outlook, they should be redirected to Office 365 mailbox.  So no matter where the users their desktop, the outlook reaches office 365
  •  Users office 2010 has been upgraded to office 2013 or 2016
    • Reason : This helps to avoid additional autodiscover dns record.  Outlook 2013 or 2016 has that capabilities.  It tries traditional autodiscovery and finally reaches the office 365 automatically.
  • Both incoming and outgoing emails are filtered in abc.com domain.
    • Reason : This helps to maintain hygiene and plus maintain single infrastructure for email gateway.
  • A new cloud based solution for MDM is introduced.  All the user needs to re-configure their device.
    • Reason : Mobile iron and Okta apps gives a very good multi-factor authentication method.  It is very simple if a user know how to download an app and follow the on screen instruction

This case study may not be perfect solution but it is definitely worth a read.  If you have suggestions on how this could be made better, drop your comments.

Incase if you missed my Part – 1 

VJ

April 9, 2017

Exchange certificate – Best Practice

Filed under: Uncategorized — vijayarelangovan @ 6:02 pm

Having worked with different exchange environment, every since the release of Exchange 2007 use of certificate has been made compulsory. It should be either self-signed or third party certificate, that should have the domain names. The best practice is to use SAN certificate.

The things that i learnt during the certificate renewal or installing a new certficate,

1. Always use exchange powershell script or exchange console to import the certificate.

Reason: i have seen few admins prefer to use certificate console to import the certificate. when you install using certificate console, it may not reflect in the exchange console when you want to assign the services.

2. Always generate a CSR from Exchagne powershell or IIS service

Reason : When you create a CSR there will be a thumbprint associated with it. So when you complete the certificate installation for the request, certificate that you install should match the thumbprint

If you install a certificate that doesnt match the thumbprint, then you might see the installation successful but it wont show in exchange powershell nor in Console. But you can find the certificate visible in certificate console on that local computer

3. Always use a SAN certificate

Reason : As you may know that there are exchange services like ews, auto-discover and so on, you need to have certificate for each services. If you have single domain certificate, then it would be expensive and add more complication to the exchange setup

April 8, 2017

Case study for Office 365 migration – Part 1

Filed under: Office 365 — vijayarelangovan @ 8:27 pm

Recently i worked on Exchange 2010 to Office 365 migration.  It is a complex environment, i had to customize too many things to be able to make this successful.  This post is to explain the challenges that i have faced and how i was able to get around the situation.  I’m not covering technical details of the migration process, but it is just a case study.

First let me tell you the existing architecture,

  • Parent company – ABC.COM
  • Child Company – XYZ.COM
  • Child domain of the child company is – UK.XYZ.COM (this is domain were Exchange environment is present)

The oragnization decision is to bring all the employees under one roof.  Atleast for now, to bring email systems to parent domain.

Existing setup is

architecture copy

  • Each users from UK.XYZ.COM have a separate AD account to access the ABC.COM resources.
  • Each users from UK.XYZ.COM are mapped to the corresponding AD account on ABC.COM
  • The password of UK.XYZ.COM users account and their corresponding AD account on the ABC.COM are sycned using Dell password sync.
  • Each users from ABC.COM have a mailbox on UK.XYZ.COM, and the email are forwarded to ABC.COM mailbox if any emails are sent.
  • If there is any email for UK.XYZ.COM coming in ABC.COM, it will be routed through the AD accounts created on ABC.COM

So, the environment is so complicated, and the job is to bring everyone under one roof when migrated to office 365.

I’m not going to explain technical details, rather I’m going to explain the challenges and how we overcome all that.

For any given architecture i feel that following should be the prime focus of an Architect,

  • Defining a Model like
    • Type of licensing
    • Identity management
  • Active Directory consideration
    • UPN identification
    • Domain trust consideration
    • attribute consideration and remediaton
    • Identification of OU to be synched
  • Exchange server consideration
    • Mailflow
    • Email domains
    • Autodicover & Exchange web services
    • Exchange certificate
    • Active sync solution/MDM
    • Message limits
    • Mailbox sizing
    • Public folder
    • Archiving and Journaling
    • SMTP relay setup
    • Third party integration
  • Network Consideration
    • Bandwidth & Utilization
    • DNS requirement
    • Internet proxies
    • Firewall ports consideration
  • End-user desktop considerations, like windows version, outlook version, anti-virus
  • Future expansion consideration

Out of the above said considerations, the challenges that needs to be addressed or discussed

Mailflow – Right now, there are 2 incoming gateway.  one for ABC.COM and one for XYZ.COM.  When we implement office 365, how this is going to affect.  How many hops an email had to travel?, How to address the email loop? and so on

Dirsync – Right the password is synced from XYZ.COM to ABC.COM DC’s through Dell password sync.  After Office 365 who is will be the authority for syching the password.  Is is ABC.COM only or Both ABC.COM and XYZ.COM? if it is single authority, then which domain should own it?

Domain name – Fortunately, both domain has a common name, @domain.com.  Can we use the same name for the user to authenticate themselves to Office 365? if they use the same @domain name, if so, how this can be federated for 2 domains?

Domain Trust – There is one way trust between XYZ.COM to ABC.COM.  Though the trust between 2 root domains are transitive, does that going to impact UPN?,

Auto-discover – Since both the domain have the same common name, after migration, how the users from each domain will reach Office365 mailbox from inside the network? External URL needs changes? or Outlook on the client machine needs to be upgraded (User have office 2010)

MDM – Users in both the domain users same MDM solution (mobile iron) but different infrastructure.  Does that need to be changed? or both the infrastructure should be integrated or redefine a new solution?

In my Part 2 post ill explain how to overcome this challenge and the resulting architecture

VJ

Create a free website or blog at WordPress.com.