Practicing with the certificates, in let's encrypt win-acme normal is created, I send and receive normal mail, https in owa and the other services

Testing with checktls, it gives me an alert message :

Cert Hostname DOES NOT VERIFY:

(mail.contoso.com != mail | DNS:mail | DNS:mail.lan.contoso.com)

I don't understand the mail.lan.contoso.com DNS error. I thought the error was the DNS SPLIT, but reading in the forum they comment on something about the error.

I understand that the other connectors should not be changed in forums, books and tutorials, nobody changes them. That is why a new connector is created to receive from the internet, to which the FQDN can be changed.

Recommendations of this forum, my dns settings :

Private AD DNS (lan.contoso.com)

Private DNS (contoso.com) SPLIT

Public DNS (contoso.com)

We currently have a hybrid on-prem/Office 365 environment.
Our Exchange is on-prem. Users are synced to an Office 365 tenant using Azure AD Connect so they can use Teams/Sharepoint etc.

We want to migrate to the cloud and remove the on-prem exchange.
For legal reasons, however, we have to move everything to a different Office 365 tenant.

What would be the best way to do this? Migrate everything to the cloud first, and then migrate to the new tenant, or migrate to the new tenant directly?

From what I've read it's not possible for an e-mail address to exist in two tenants, so we can't just set AD Connect to the new tenant without first removing it from the old tenant, right?

Instinctively I would set up users and accounts first in the new tenant first before migrating mailboxes and switching over domains and MX records, but I don't think that's possible.

Thanks!

I'm currently in the middle of developing a lab environment to migrate our mixed Exchange 2010 and 2013 environment to Exchange 2016.

I've been running 1x 2013 and 2x 2016 in co-existence in the lab for a few weeks now, and it's worked well - I've done testing for RPC, OWA, ActiveSync and EWS. Everything seems to work fine.

This week I've tried to finalise my deployment by introducing a load balancer in front, with a plan to provide round-robin LB between my 2013 and 2016 CAS nodes. From all I've researched 2013 and 2016 CAS are totally compatible for the CAS role in that they will gladly proxy between each other. And to be sure my manual testing via each CAS (without a load balancer) seems to show this.

But now that I've introduced HA Proxy in front, OWA seems to not want to work properly.

Symptoms

Here's some symptoms:

• When I log in via 2016 OWA to a 2013 mailbox, it does login correctly, redirects me, and starts loading the inbox. But after a second or two of loading the inbox, I get redirected back to the OWA login page as if I'd never logged in.

• I can repeat this multiple times and it seems to do the same thing, as long as I login via a 2016 CAS.

• Sometimes when I login via 2016 it will just hang with "Still working on it". This is far less frequent then just logging me back out, though.

• Some times it redirects back to the login page so quickly I can't even tell I logged in at all, and has no error message. It's just a flash then back to the login page.

• I've tried from reasonably up to date versions of both Chrome and Firefox, on Mac and Windows 8.1. So it's not an end-device issue.

• If I login to a 2013 mailbox via OWA on the 2013 CAS, even through the load balancer, it seems to login correctly first time.

• I've got one IP on the load balancer which then proxies traffic to each CAS node in a round-robin fashion. This is what I use to test my LB. I've got other IPs pointing directly to individual CAS nodes.

• If I login directly to a 2016 CAS node to a 2013 mailbox, this works fine. It's one one I login to a 2016 CAS via the load balancer that the issue appears.

• Interestingly, I just noticed the exact same issues occur even if logging into a 2016 mailbox. So as long as I login to a 2016 CAS, it logs back out.

• Once I login successfully via the 2013 CAS, I can refresh the page several times and the session will still stay open. To me this indicates that proxying must be working OK to some extent once the session is established, because my LB is round-robin so the traffic should be getting re-distributed over various CAS nodes each time I refresh the OWA page.

It seems pretty clear to me that there are others experiencing similar issues with Exchange 2010 - 2016 when behind a load balancer. Unfortunately this is our first time using a load balancer as we're moving from a single CAS to 3 with this upgrade to Exchange 2016.

I've found a fair few posts with similar symptoms:

• https://devcentral.f5.com/questions/microsoft-exchange-2013-iapp-cant-login-to-owa-or-ecp-if-more-than-one-server-is-active-in-pool

• http://www.360ict.nl/blog/owa-does-not-work-after-load-balancing-exchange-2016-while-using-kemp-loadbalancers/

• https://devcentral.f5.com/questions/exchange-2013-session-affinity-once-again

What I've Tried

• I've confirmed that all our SSL frontend (third-party CA) certificates match with the same thumprint and serial across all CAS nodes. I've read that this can impact things. I am using a production certificate to properly test my lab.

• The backend certs are left as the default Microsoft Exchange certificate, and from what I've read this is fine. I actually tried using our wildcard cert on the backend anyway, and it seemed to break everything.

• I've verified that when accessing the 2016 CAS without a load balancer, things seem to work fine. Based on this, I thinking if I was to enable full session persistence on the load balancer so a particular user only deals with one CAS, it would fix the problem. But then, I shouldn't have to do that. And it makes me worry there's a deeper error to solve.

• I've enabled IIS Failed Request tracing. I've found some reports of 500 errors for powershell requests. But they seem related to failed health monitoring requests, and don't necessarily seem to line up time-wise with my OWA tests logging me back out.

• I've done some basic checking via Wireshark to look for anything weird. I've noticed that a single OWA page load is definitely distributed at least over multiple CAS nodes. Sometimes both 2016 nodes, sometimes a 2016 and a 2013 node.

• I did notice in my capture (on the load balancer) that during a single failed login attempt, I kept getting repeated 440 Login Timeout responses from the CAS nodes. In this case I got multiple of these, at least one from each CAS node.

• There's so many individual HTTP requests after the initial login request, it's hard to pin-point where the problem is, but it seems like a bunch of OWA service.svc requests start to be sent by the browser, and at some point they all being to return the same 440 Login Timeout error as a response from the CAS node. Then eventually we are redirected back to the login page.

• I haven't yet found anything through my research what is actually causing the 440 login timeouts, or if it's expected behaviour etc...

• I've re-checked all my Virtual Directory settings against our production setup. They look OK.

EDIT: 2017-03-04

• I have tried multiple different VirtualDirectory internal and external URL combinations. exchange.isp.com.au is the internal AD Domain (this matches the live setup). The external URL for the lab is exchlab.isp.com.au.

• I have tried:

  • exchlab.isp.com.au for both internal and external.
  • exchange.isp.com.au for both internal and external.
  • I stuck with exchlab for external and exchange for internal. None of these combinations made a difference.

• Since then, I have also added Cookie-based session persistence in HA Proxy, and it seems to have made a difference. I have only done persistence for OWA and ECP, but the rest are not persistent. Things to note:

  • I am no longer logged back out of OWA repeatedly. It's become much more stable.
  • It still happens the first time I log out of a mailbox (e.g. 2013) and login to a mailbox of a different version. (e.g. 2016). After I get logged out the first time, though, I can now log back in successfully.
  • If I log out of a mailbox and back in too fast (within 10 seconds) then I am often kicked back out instantly.

• I also decided to proceed with my testing of HA Proxy for services besides OWA. And I can confirm:

  • Outlook Anywhere load balances over all 3 CAS nodes and works fine.
  • EWS also load balances over all 3 and works fine.
  • Active Sync seems to only want to go over the 2x 2016 CASes but also load balances fine.

Things I need to Try

• Reset all my virtual directories
• Resync the IIS IUSR accounts: https://technet.microsoft.com/en-us/library/dd789741(v=exchg.80).aspx
• Verify IUSR Authorisation level.

I haven't actually done these yet as I feel like there's an actual configuration issue. Also since everything seems to work without the load balancer, I can't see this helping.

More Environment Info

Some more details on the lab environment I'm testing in.

• Our load balancer config is taken from here: https://www.haproxy.com/doc/aloha/7.0/deployment_guides/microsoft_exchange_2013.html#aloha-configuration -- we're using the "SSL Offloading - HTTP Reverse Proxy" config (advanced version).

• We are doing SSL Offloading based on this guide: https://serversforhackers.com/using-ssl-certificates-with-haproxy and this guide: https://jaapwesselius.com/2014/02/28/exchange-2013-sp1-ssl-offloading/

• Our Exchange 2013 box is running SP1 \w CU11

• Our Exchange 2016 boxes are running CU2. I'm intentionally avoiding upgrading to CU4 as I want to test and document a graceful upgrade procedure with the load balancers.
• We are running 2x additional VMs as dedicated ADs. No AD on the Exchange nodes.

• All Windows systems (including AD) are running Windows 2012 R2.

• Our router is a Linux box doing NAT. The Load balancer is in the same /24 subnet as the Exchange servers and AD boxes.

• LB HTTP front end is .7 and Exchange boxes are .1, .2 and .3

• We are also running a simple HTTP redirect on dedicated IPs of each Exchange box on .4, .5 and .6. Though I'm planning to shift this simple redirect to the load balancer as it can easily do HTTP redirects.

Relevant bits of my load balancer config:

    # This is the L7 HTTPS Front End
    # ------------------------------
    # We redirect to different backends depending on the URI
    # Each backend has its own separate health checks. So that each service can fail on an Exchange CAS node without affecting the other services.
    frontend ft_ISP_EXCHANGE_https
      bind 172.16.10.7:80 name INT_http
      bind 172.16.10.7:443 name INT_https ssl crt wildcard.isp.com.au.pem # Specify SSL Cert for offloading.
      mode http
      option http-keep-alive
      option prefer-last-server
      no option httpclose
      no option http-server-close
      no option forceclose
      no option http-tunnel
      timeout client 600s
      log global
      capture request header Host len 32
      capture request header User-Agent len 64
      capture response header Content-Length len 10
      # log-format directive must be written on a single line
      # it is splitted for documentation convnience
      log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ {%sslv/%sslc/%[ssl_fc_sni]/%[ssl_fc_session_id]}\"%[capture.req.method]\ %[capture.req.hdr(0)]%[capture.req.uri]\ HTTP/1.1
      maxconn 1000
      acl ssl_connection ssl_fc # Set ACL ssl_connection if ssl_fc returns TRUE

      # Route request to a different backend depending on the path:
      # http://serverfault.com/questions/127491/haproxy-forward-to-a-different-web-server-based-on-uri
      acl host_mail hdr(Host) -i exchange.isp.com.au
      acl path_slash path /
      acl path_autodiscover path_beg -i /Autodiscover/Autodiscover.xml
      acl path_activesync path_beg -i /Microsoft-Server-ActiveSync
      acl path_ews path_beg -i /ews/
      acl path_owa path_beg -i /owa/
      acl path_oa path_beg -i /rpc/rpcproxy.dll
      acl path_ecp path_beg -i /ecp/
      acl path_oab path_beg -i /oab/
      acl path_mapi path_beg -i /mapi/
      acl path_check path_end -i HealthCheck.htm
      # HTTP deny rules
      http-request deny if path_check
      # HTTP redirect rules
      http-request redirect scheme https code 302 unless ssl_connection # Force SSL
      http-request redirect location /owa/ code 302 if path_slash host_mail # Redirect / to /owa
      # HTTP routing rules -- This is where we decide where to send the request
      # Based on HTTP path.
      use_backend bk_ISP_EXCHANGE_https_autodiscover if path_autodiscover
      use_backend bk_ISP_EXCHANGE_https_ews if path_ews
      # other services go here
      default_backend bk_ISP_EXCHANGE_https_default



      # Backends
    # --------
    # Now we define each backend individually
    # Most of these backends will contain all the same Exchange CAS nodes, pointing to the same IPs
    # The reason we define each backend individually is because it allows us to do separate Health Checks
    # for each individual service running on each CAS node.

    # The failure of one service on a CAS node does not exclude that CAS node from participating in other
    # types of requests. This gives us better overall high-availability design.

    # HTTPS OWA
    # I have added additional comments on this definition, but the same applies to all Exchange HTTPS backends.
    backend bk_ISP_EXCHANGE_https_owa
      balance roundrobin # Use round-robin load balancing for requests
      option http-keep-alive # Enable HTTP Keepalives for session re-use and lowest latency for requests.
      option prefer-last-server # Prefer to keep related connections for a session on the same server.
      # This is not the same as persistence, and is mainly to try and take advantage of HTTP Keepalives.
      # See here for an example of why this is needed: http://stackoverflow.com/questions/35162527/haproxy-keep-alive-not-working-as-expected

      no option httpclose # Disable all options that are counter to keepalives
      no option http-server-close
      no option forceclose
      no option http-tunnel
      mode http # Operate in L7 HTTP Mode (vs TCP mode etc)
      log global
      option httplog
      option forwardfor # Enable insertion of the X_FORWARDED_FOR HTTP Header
      option httpchk GET /owa/HealthCheck.htm # Use L7 HTTP Health Check. This is recommended by Microsoft.
      http-check expect string 200\ OK
      default-server inter 3s rise 2 fall 3
      timeout server 60s
      # Define CAS Nodes for this service. We're using SSL offloading to allow L7 HTTP Checks
      # We've avoided SSL Bridging as that would halve our LB's throughput.
      server ISP_exch16_syd_01 172.16.10.2:80 maxconn 1000 weight 10 check
      server ISP_exch16_syd_02 172.16.10.3:80 maxconn 1000 weight 10 check
      server ISP_exch13 172.16.10.1:80 maxconn 1000 weight 10 check

I have started having an issue when trying to change a user/mailboxes country/region through Exchange Admin Center in Exchange 2016.

When attempting to do so, I get this error:

Active Directory operation failed on DC. This error is not retriable. Additional information: Insufficient access rights to perform the operation.
Active Directory response: 00002098: SecErr: DSIS-03150E49, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Other reports of this error do not seem to have a resolution that applies to us. Oddly, If I go into ADUC, and find the same user account, I can easily change the country/region using my same domain login (member of domain admins and enterprise admins).

Does anyone have any thoughts on why I can change this attribute directly through AD but not Exchange?

EDIT: Also have this post on the TechNet forum trying to identify the cause of this issue: Technet Post

I have never setup an Exchange server before.

I am trying to setup an Exchange 2016 server.

I got the pre-reqs setup; .NET 4.5.2 Microsoft Unified Communications Managed API 4.0 Core Runtime 64-bit.exe

I did the setup, checked off MailBox role and told it to install all the pre-reqs that it could do on it's own.

The only warnings I got were about Exchange 2010 roles no longer being able to install.

Now I'm at post setup. I was able to log in to the webpage portal and I can configure anything in there since I'm the administrator.

--- The Problem ---

So, what now?

This is a test network;

192.168.1.1 - Linksys Router
192.168.1.2 - Server 2012r2 Active Directory Domain Controller, DNS, DHCP
192.168.1.3 - Server 2012r2 with Exchange 2016
129.168.1.100 - Client PC (Win 10)

ADDC Settings:
Domain is named ad.testbed.com
NetBios is named testbed
Server is named Core

All firewalls disabled

I'm trying to get Thunderbird to access the Exchange server, with no success. I've tried doing a manual configuration.

I added a user (Kayot) to both the ADDC and setup an email account through the portal.

Settings I've tried:

imap.ad.testbed.com/192.168.1.3 Auto/993 Autodetect/SSL/TLS Autodetect/Normal password
smtp.ad.testbed.com/192.168.1.3 Auto/465 Autodetect/SSL/TLS Autodetect/Normal password

I also tried using Outlook 2003 with Exchange as the mail server.

I created a public folder mailbox to fix an issue where I couldn't link the Exchange to my Outlook program. Issue: "Your Administrator has blocked this version of Outlook"

I keep loosing connection to the server. When I click on the mailbox it says the folder can't be accessed.

I am completely lost. I feel that if I could get Thunderbird to link to the Exchange server then I would be one step closer to figuring out this mess.

I can get hmailserver (I swap OS Harddisks) to connect with the following settings:

192.168.1.3 Auto Autodetect Autodetect
192.168.1.3 Auto Autodetect Autodetect

So I'm stumped. Tutorials for Exchange do the setup only, or are for things that come with a more complex setup. This is a single system connected to an Active Directory system and being accessed by a single client machine. Nothing special. I want to access it internally first to make sure it works. I feel I am missing some simple step.