Problems after upgrade to CU14
Hi, I'm in the process of migrating from Exchange 2013 CU23 to Exchange 2019. I installed Exchange 2019 CU13 on Win2022 Server, in coexistence with our 2013 and everything was looking good. Before starting with the testing to route emails through 2019, I checked that CU14 was released recently, so I download/install the CU14 in upgrade mode (with the no EP flag) to have the last build, and now I'm having problems with virtual directories, mailboxes, and so ON. Already run the healtchecker powershell scripts and nothing out of the ordinary. Some of the problems I'm having: 1. When I clic on the 'authentication' tab in any Virtual Directory (ECP, OWA, EWS) I got this error: "The task wasn't able to connect to IIS on the server <FQDN>. Make sure that the server exists and can be reached from this computer: The RPC server is unavailable." The other tabs don't throw me any errors, but almost all options are greyed-out. 2. In SERVERS > DATABASES, when entering the properties of any Database that are on the new EX2019, I got this error: 'Exchange can't connect to the Information Store service on server <FQDN>. Make sure that the service is running and that there is network connectivity to the server.' I cannot create a new Database neither and the status of the currents 2019 Mailbox databases says Uknown and BadCopyCount = 1. 3. SERVERS > CERTIFICATES: Cannot see any Cert here for the EX2019. The error I get: "Cannot connect to the remote procedure call service on the server named <servername>. Verify that a valid computer name was used and the Microsoft Exchange Service Host service is started." Already check: - Binding of the Certificate 'Microsoft Exchange 'on the BackEnd and our Public Certificate on the Frontend Server. - All Exchange Services are up and running. - Restart of IIS. It appears that is something with permissions and/or with IIS that breakdown after the installation, but still don't know what it is. Al things related to the 2013 environment appears to be normal and functioning. according. Something I noticed, on the Certificate error it says the name of the server, and in the other errors, it says the FQDN of the server. Please guide me here, what could be the problem and what to check/confirm. Thanks in advance.
Exch 2016 Hybrid to Exch 2019 Hybrid /TenantOrganizationConfig queries
Hi All, I've searched posts here and have looked at the Microsoft Migration guide, maybe I am looking at things wrong... it has been a long day so any feedback would be appreciated! Looking to introduce Exchange 2019 CU12 into a patched Exchange 2016 multi-site hybrid environment with the aim to move everything to 2019, re-point hybrid at the 2019 servers and decommission Exchange 2016. Preparing the domain in the past has been a form of Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareSchema then Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAD once the domain has replicated before deploying the first 2019 Exchange box. The preparing AD article has an info snipit: If you have a hybrid deployment configured between your on-premises organization and Exchange Online, add the /TenantOrganizationConfig switch to the command. For existing environments, you don't need to use the /OrganizationName and /TenantOrganizationConfig switches. I'm seeing reference to the following article: https://learn.microsoft.com/en-us/exchange/troubleshoot/administration/error-when-running-setup-prepareschema It sounds like if 2016 exists in Hybrid form, skip the /PrepareSchema and move straight to Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAD /TenantOrganizationconfig:C:\TenantConfig.xml to also take care of the /PrepareSchema flag. Queries I have: - Is this the way forward with hybrid environments requiring a schema update, or only deploying a new co-existence version into the environment? - Does this change the hybrid configuration in the 2016 environment, is their impact to the tenant\on-premises communication to plan for? - Should you rerun the hybrid wizard after completing the above steps for the existing hybrid servers? - Is refreshing the schema in AAD Connect now a recommended step post schema update? I might be reading too much into it but appreciate feedback from those who might know off the top of their head. Thanks!
Outlook Cannot Connect After Setting Up Exchange 2016 Coexistence with Exchange 2010
Currently have Exchange 2010 SP3 environment with load balancers. Kerberos is enabled for Outlook connectivity. All SPNs are still pointing to the Exchange 2010 exchangeASA$ account in AD. Outlook Anywhere is enabled. Installed Exchange 2016 infrastructure in two different Active Directory sites (which are separate from the Exchange 2010 AD site). Note we have not set up an additional ASA for Exchange 2016, nor have we applied an account in the Client Access Server settings. Exchange 2016 servers have the following settings: MAPI Virtual Directory: Identity : EX16-DB-01\mapi (Default Web Site) IISAuthenticationMethods : {Ntlm, OAuth, Negotiate} InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate} ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate} Autodiscover: InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth} EWS Virtual Directory: Identity : EX16-DB-01\EWS (Default Web Site) CertificateAuthentication : InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth} ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth} LiveIdNegotiateAuthentication : WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : False DigestAuthentication : False WindowsAuthentication : True OAuthAuthentication : True AdfsAuthentication : False When we change DNS to point to Exchange 2016 servers, Exchange 2016 and Exchange 2010 mailbox users cannot create an Outlook 2016 profile or access their mailboxes. If we remove “Negotiate” from the MAPI Authentication Settings (in Italiacs above), then Exchange 2016 mailbox users can create profiles and access their mailboxes. However, Exchange 2010 mailbox users still cannot access their mailboxes. Questions: If we add Negotiate to MAPI Virtual Directory authentication, are we required to have ASA for Exchange 2016 set up, or will Outlook continue on and use NTLM? It appears from our issue that it MUST be set up. Is this true? What are the proper authentication settings for the different virtual directories listed above? If we use Kerberos with Exchange 2016 (which it appears may be the case), what should be set to Negotiate and what should be set to NTLM?