These are related to Exchange Server and topics along those lines.
I have been working on updating my skillset to M365 and passed the final exam today to achieve it. I am hoping that the certification will assist me with attaining work moving forward.
You can verify at the following URL:
https://www.youracclaim.com/badges/8bb7d636-b898-43ec-b283-0dea03586896/public_url
In my environment, I have a Windows Server (2019) Core edition server installed with Exchange 2019. Most of the time, I have to get on the server to run PowerShell commands for maintenance purposes, etc…
Well, by default, Windows Server Core opens the command prompt when you logon and then I have to manually open PowerShell from there to run cmdlets, etc…
However, if you would like to change the default cmd to PowerShell, you can change it by changing the Registry value.
The Registry that I’m talking is located under the following location:
1 | HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon |
The easiest way I see to change the value is to use the Set-ItemProperty cmdlet within PowerShell.
Open Windows PowerShell within Server Core command prompt. You can type “PowerShell” on your command prompt.
Then, enter the following command on PowerShell console and hit enter:
1 | Set-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon' -Name Shell -Value 'PowerShell.exe' |
Once completed, you will need to reboot the computer from PowerShell:
1 | Restart-Computer -force |
When the computer has rebooted and you have logged on, PowerShell should load by default instead of Command Prompt.
Now, since I have an Exchange Server installed on this server, there is a Command in the $bin directory called LaunchEMS.cmd that will load the Exchange Management Shell for you. So instead of loading just PowerShell, I tell WinLogon to load Exchange Management Shell so that I do not have to do any additional typing or searching for EMS on the box. Remember, Server Core has no GUI!
I run the same commands as above, but just change the value to LaunchEMS.cmd
1 | Set-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon' -Name Shell -Value 'LaunchEMS.cmd' |
Then Restart the Computer:
1 | Restart-Computer -force |
Once Rebooted, you can logon and EMS will be the only window prompt that loads in the shell!
NOTE: You can always run cmd from the prompt to open Command Prompt and also run PowerShell.exe to open regular PowerShell from the EMS Session Window.
REFERENCES:
Windows Server Core: How to start PowerShell by Default
As many of you that follow Exchange have knowledge of, Microsoft releases their updates for Exchange Server every 3 months. Below is the latest update for Exchange Server 2016. I do not run 2016 any longer in my lab, but please post if you have issues with the installation and I can investigate!
Cumulative Update 17 for Microsoft Exchange Server 2016 was released on June 16, 2020. This cumulative update includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. These fixes will also be included in later cumulative updates for Exchange Server 2016.
This update also includes new daylight saving time (DST) updates for Exchange Server 2016. For more information about DST, see Daylight Saving Time Help and Support Center.
This cumulative update fixes the issues that are described in the following Microsoft Knowledge Base articles:
Download Cumulative Update 17 for Exchange Server 2016? (KB4556415) now
Download Exchange Server 2016? CU17 UM Language Packs now
Notes
This cumulative update requires Microsoft .NET Framework 4.8.
A component that’s used within Exchange Server requires a new Visual C++ component to be installed together with Exchange Server. This prerequisite can be downloaded at Visual C++ Redistributable Packages for Visual Studio 2013. For more information, see KB 4295081.
For more information about the prerequisites to set up Exchange Server 2016, see Exchange 2016 prerequisites.
You may have to restart the computer after you apply this cumulative update package.
You don’t have to make any changes to the registry after you apply this cumulative update package.
After you install this cumulative update package, you can’t uninstall the package to revert to an earlier version of Exchange Server 2016. If you uninstall this cumulative update package, Exchange Server 2016 is removed from the server.
REFERENCES:
Exchange Server 2016 CU17
As many of you that follow Exchange have knowledge of, Microsoft releases their updates for Exchange Server every 3 months. Below is the latest update for Exchange Server 2019. I will be installing it very soon and will post any issues I may have with Server Core and GUI versions of Windows 2019.
Cumulative Update 6 for Microsoft Exchange Server 2019 was released on June 16, 2020. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. These fixes will also be included in later cumulative updates for Exchange Server 2019.
This update also includes new daylight saving time (DST) updates for Exchange Server 2019. For more information about DST, see Daylight Saving Time Help and Support Center.
This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:
To get Cumulative Update 6 for Exchange Server 2019, go to Microsoft Volume Licensing Center.
Note The Cumulative Update 6 package can be used to run a new installation of Exchange Server 2019 or to upgrade an existing Exchange Server 2019 installation to Cumulative Update 6.
This cumulative update requires Microsoft .NET Framework 4.8.
A component that’s used within Exchange Server requires a new Visual C++ component to be installed together with Exchange Server. This prerequisite can be downloaded at Visual C++ Redistributable Package for Visual Studio 2012.
For more information about the prerequisites to set up Exchange Server 2019, see Exchange 2019 prerequisites.
You may have to restart the computer after you apply this cumulative update package.
You don’t have to make any changes to the registry after you apply this cumulative update package.
After you install this cumulative update package, you can’t uninstall the package to revert to an earlier version of Exchange Server 2019. If you uninstall this cumulative update package, Exchange Server 2019 is removed from the server.
REFERENCES:
Exchange Server 2019 CU6
In my experience with doing Exchange migrations to the cloud, there always seemed to be an issue with EWS throttling causing very slow mailbox moves. The remediation to this was to always contact Microsoft EXO Support and open a ticket to request that your EWS throttling for your tenant be lifted so you could move your mailboxes more quickly.
The reason for the EWS Throttling was to keep large amounts of data from flooding the front end server farm possibly causing a temporary outage or corruption of data going to the cloud since there are literally thousands of customers going through the same server farm and possibly migrations. Throttling was a way to keep everything in check.
Microsoft recently made an interesting change to the automated support handling capabilities of the Microsoft 365 admin center to handle requests for Exchange Web Services (EWS) throttling to be lifted for up to 90 days without human intervention.
Once the setting is changed in the tenant, it will be effective after about 15 minutes for replication to the server farm. You should then be able to run your migrations at full speed.
NOTE: Changing this setting is only effective for EWS migrations and NOT IMAP Migrations (such as from G-Mail).
Having this option online in the portal saves a tremendous amount of time when working to get your Exchange migrations to the cloud completed. Hopefully there will be more to come. I just hope it doesn’t keep me out of a job!
REFERENCES:
Microsoft Automates EWS Throttling
Since the COVID-19 virus has managed to get me laid-off and not working, I have not had too much to post in the past months. And although it has wavered greatly, I will remain positive and hope that someone will see the value that I can bring to their organization in the near future.
With that said, I wanted to repost this article that was sent to me as this issue arises quite often in the workplace when someone has left for vacation and is not in the office. So, here it is:
Out of Office replies can sometimes be a bit of a mystery to people; how do they work? What do you do if they don’t work? In this blog post, we will discuss the bits and pieces of Out of Office and some of the main reasons why an Out of Office (aka. OOF) reply might not get delivered to users. Note that while we are writing this from the viewpoint of an Exchange Online configuration, many of same things can be applied to on-premises configuration also. By the way – did you ever wonder why “OOF” is used instead of “OOO”? If you did, see this!
Out of Office replies are also known as OOF (or OOO) replies or automatic replies. They are Inbox rules that are set in the user’s mailbox by the client. OOF rules are server-side rules, so the response is sent regardless of whether a client is running, or not.
There are several ways of setting up automatic replies:
First, it can be set up as an automatic reply feature from Outlook, like this. It can also be configured using other clients, such as Outlook on the web (OWA), PowerShell command (Set-MailboxAutoReplyConfiguration). Admins can set up OOF replies on behalf of (forgetful) users from the M365 Admin Portal.
Other than using built-in OOF functionality, another thing people sometimes do is use rules to create an Out of Office message while they are away.
By design, Exchange Online Protection uses the high risk delivery pool (HRDP) to send the out of office replies, because they are lower priority messages.
There are three types of OOF rules: Internal, External and Known Senders (Contact list). They are stored in the mailbox with the names in the following table. If a mailbox has set only Internal OOF, there will be no external rule created and the mailbox will have one OOF rule.
| Type | Message Class | PR_RULE_MSG_NAME |
| Internal | IPM.Rule.Version2.Message | Microsoft.Exchange.OOF.KnownExternalSenders.Global |
| External | IPM.Rule.Version2.Message | Microsoft.Exchange.OOF.AllExternalSenders.Global |
| Known External | IPM.ExtendedRule.Message | Microsoft.Exchange.OOF.KnownExternalSenders.Global |
Note: Apart from OOF rule, other rules like the Junk Email rule will also have the “IPM.ExtendedRule.Message” message class; the MSG_NAME will determine what the rule is for.
All Inbox rules can be viewed using MFCMapi tool:
Logon > profile that you are accessing > Top of information store > Inbox > right click ‘Open associated contents table’. They are listed under the Message Class column. All Inbox rules will have the same message class IPM.Rule.Version2.Message and there is one message class and name for each Inbox rule.
For all rules, the name of the rule is in stored in the PR_RULE_MSG_NAME property. So, if there are 4 Inbox rules, there will be 4 IPM.Rule.Version2.Message one for each rule, and the name of the rule is stored in PR_RULE_MSG_NAME.
OOF rules in MFCMapi:
And OOF rule templates in MFCMapi:
OOF response is sent once per recipient. Recipients to whom the OOF was sent are stored in the OOF history and are cleared out when the OOF state changes (enabled/disabled) or the OOF rule is modified. OOF history is stored in the user’s mailbox and can be seen using MFCMapi tool at: Freebusy Data > PR_DELEGATED_BY_RULE.
Note: If you want to send response to the sender every time instead of just once, you can apply mailbox server side rule “have server reply using a specific message” to send automatic reply instead of using the OOF rule. This server-side rule will send reply to the sender every time a message is received.
Now that we know what OOF replies are and how they are stored on the server, we can move on to address some of the scenarios where OOF is not sent to the sender. We will also discuss possible fixes and some more frequently seen issues you may have with OOF configuration.
The first category of issues we will talk about are issues related to OOF replies not being received by the sender of the original message.
When OOF doesn’t seem to be sent for all users in the tenant, usually there is a transport rule causing the issue. Check all the transport rules that may apply to the affected mailbox using step two of this article.
If you suspect a delivery problem, run a message trace from the Office 365 tenant. We know that OOF response is sent back to the original sender of the message, so for OOF messages, the sender of the original message becomes the recipient when tracking. We should then be able to tell if OOF reply has been triggered and sent to external or internal recipient. If a Transport rule is blocking the OOF response, the message trace will clearly show you that.
There is one scenario I would like to highlight when it comes to transport rules blocking OOF replies. Let’s assume that you moved the MX record to a 3rd party anti-spam solution; you have created a transport rule to reject any email coming from any other IP address than the 3rd party anti-spam.
The transport rule will look something like this:
Description:
If the message: Is received from ‘Outside the organization’ Take the following actions: reject the message and include the explanation ‘You are not permitted to bypass the MX record!’ with the status code: ‘5.7.1’ Except if the message: sender ip addresses belong to one of these ranges: ‘1xx.1xx.7x.3x’
ManuallyModified: False
SenderAddressLocation: Envelope
As OOF replies have a blank (<>) Return-Path, you will see that the rule is unexpectedly matching the transport rule and the OOF responses are getting blocked.
In order to fix this, you can change the transport rule property of ‘Match sender address in message’ to ‘Header or envelope’, so the checks will also be done against ‘From’ (also known as the ‘Header From’ address), ‘Sender’ or ‘reply-to’ fields. More information about the mail flow rule conditions is here.
If the affected mailbox is the one which is configured under JournalingReportNdrTo, OOF replies will not be sent for that mailbox. Moreover, journaling emails may be affected as well. It is recommended to create a dedicated mailbox for the JournalingReportNdrTo setting. Alternatively, you can set it to an external address.
For more details on how to solve this, please see this KB Article.
If the affected user mailbox has SMTP forwarding enabled, OOF replies won’t be generated. This can be checked in user mailbox settings (OWA):
In PowerShell:
1 | Get-Mailbox -Identity Daniel | fl DeliverToMailboxAndForward, ForwardingSmtpAddress, ForwardingAddress |
Or, in the M365 Portal, user properties:
Please follow the action on step one of this article for more information.
Remote domains offer you (among other settings) the opportunity to set the type of OOF reply that can be sent to users.
These types are the following:
For more information about each of these OOF types, please refer to AllowedOOFType parameter in our Set-Remotedomain document.
The Out of Office type can be checked from Exchange Admin Center > Mail flow > Remote domains
Or, with PowerShell:
1 | Get-RemoteDomain | ft -AutoSize Name, DomainName, AllowedOOFType |
You need pay attention to what OOF type you have set up, as this will impact the OOF response and OOF may not be generated at all if the configuration is incorrect. Let’s assume you have a hybrid organization with mailboxes hosted both in Exchange on-premises and Exchange Online. In this scenario, by design only external messages will be sent to on-premises while AllowedOOFType is set to External. To be able to send internal OOF messages to on-premises in hybrid environment, you need to set the AllowedOOFType to InternalLegacy.
You also have option to send external Out of Office replies only for contacts at the mailbox configuration level (ExternalAudience: Known). This can make automatic replies not being sent to anyone external but contacts. The command to check the configuration is:
1 | Get-MailboxAutoReplyConfiguration daniel | fl ExternalAudience |
Another setting on remote domains is one which lets you dictate whether you allow or prevent messages that are automatic replies from client email programs in your organization.
This can be found in Exchange Admin Center > Mail flow > Remote domains
Or by running this PowerShell cmdlet:
1 | Get-RemoteDomain | ft -AutoSize Name, DomainName, AutoReplyEnabled |
Note: If this option is set to false, no automatic replies will be sent to users for that domain. This setting takes precedence over the automatic replies set up at the mailbox level or over the OOF type (discussed above).
Please, keep in mind that $false is the default value for new remote domains that you create as well as the built-in remote domain named Default in Exchange Online.
Pretty self-explanatory, that one!
If you investigate an OOF reply issue and in the message trace you find the following error message:
“550 5.7.750 Service unavailable. Client blocked from sending from unregistered domains.”
You should reach out to Support to find out why the unregistered domain block was enforced.
There are some other scenarios that might come up when working with OOF replies, let’s cover those next!
This is likely due to a duplicate Inbox rule or the OOF history limit. The OOF history has a limit of 10,000 entries, if this threshold is hit, OOF will continue to be sent to recipients that are not already in the list as any new users can’t be added to the list. All users already in the list will not receive duplicate OOF replies. For more information you may want to check this article or follow the action plan below.
Now, you can check again whether the OOF feature works as expected and symptoms do not occur.
While attempting to access automatic replies from the Outlook client, an error message is received saying that “Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later.”
To narrow down this issue, you should perform the following steps:
By default, the RulesQuota has a maximum quota which is calculated by the size of the rules (not the number of rules). Maximum is 256 KB (262,144 bytes).
We have encountered scenarios in which OOF messages are still being sent, although it is disabled. Most of the time, we found that the rule is created manually by the end users using the out-of-office template.
So, as you can see, there is quite a bit that goes into troubleshooting OOF Replies and it is not all straight forward.
This was a great article released by the Exchange Team Blog today, and as I have been dealing with MANY customers still having Exchange 2010, I wanted to have this available for quick review! It has great links and steps to consider when finally getting off Exchange 2010.
As many of you know from the previous post regarding Exchange On-Premises Best Practices for Migrations from 2010 to 2016 the end of support for Exchange 2010 is quickly approaching. We’ve created this post to cover the best practices for decommissioning an Exchange 2010 environment after the migration has completed.
Uninstalling Exchange 2010 is as easy as running Setup and selecting to remove the server roles, but there are prerequisites to removing the roles and legacy items left over, which should be removed.
This post is intended to provide best practices to plan for and complete the Exchange 2010 decommission. Please note that since there are many different types of deployments and configurations it is difficult to cover all scenarios, but many of the common steps are included here. Please plan the decommission process carefully.
As a general statement, here are some things that we want to caution against:
This post assumes that your organization is maintaining some Exchange presence on-premises, whether Exchange 2013 or 2016 (we do not mention Exchange 2019 in this post because it cannot coexist with Exchange 2010). If your organization has moved all mailboxes to Office 365 and is in a Hybrid environment, we are assuming you will maintain an Exchange footprint per Scenario 2 in How and when to decommission your on-premises Exchange servers in a hybrid deployment.
Once you’ve completed the migration from Exchange 2010 to, let’s say, Exchange 2016, you should prepare the 2010 environment prior to decommissioning the servers. The following steps to consider are separated into server roles when preparing for a soft shut down and preparing for the removal of server roles.
Review all namespaces (e.g. DNS records and load balanced virtual IP addresses) used for client connectivity and ensure they are routing to the 2016 environment. These are all the names that are published for Outlook Anywhere, AutoDiscover, and all Exchange Virtual Directories.
Tip: Verify that all clients such as ActiveSync, Outlook, EWS, OWA, OAB, POP3/IMAP, and Autodiscover are no longer connecting to the legacy Exchange servers. Verification of this can be done by reviewing the servers’ IIS Logs with Log Parser Studio (LPS). LPS is a GUI for Log Parser 2.2 and it greatly reduces the complexity of parsing logs. LPS can parse large sets of logs concurrently (we have tested with total log sizes of >60GB). Please refer to the following blog post with tips and information on using LPS.
Make sure that the Service Connection Point (SCP) is moved to Exchange 2016 as discussed in the Exchange On-Premises Best Practices for Migrations from 2010 to 2016 post under the Configure Autodiscover SCP for Internal Clients section.
1 | Get-ExchangeServer | ? {$_.AdminDisplayversion -like "Version 14.*" -and $_.IsClientaccessServer -eq $true} | Get-ClientAccessServer | Select Name, FQDN, AutoDiscoverServiceInternalUri |
If present, ensure that if the AutoDiscoverServiceInternalURI routes to an Exchange 2016 endpoint. You can also remove this value by setting the AutoDiscoverServiceInternalURI to $Null.
1 | Set-ClientAccessServer -Identity <Exchange2010> -AutoDiscoverServiceInternalURI https://autodiscover.contoso.com/AutoDiscover/AutoDiscover.xml |
Follow the items below to review all mail flow connectors. We will not be removing connectors themselves, simply auditing to ensure that the server is ready to be decommissioned.
Review the send connectors and ensure that the legacy servers have been removed and Exchange 2016 servers have been added. Most organizations only permit outbound network traffic on port 25 to a small number of IP addresses, so you may also need to review the outbound network configuration.
1 2 | Get-SendConnector | Select Name,SourceTransportServers Get-ForeignConnector | Select Name,SourceTransportServers |
Review the receive connectors on legacy servers and ensure they are recreated on your Exchange 2016 servers (e.g. SMTP relay; anonymous relay; partner, etc.). Review all namespaces (e.g. DNS records and load balanced virtual IP addresses) used for inbound mail routing and ensure they are terminating against the Exchange 2016 environment. If your legacy Exchange servers have any custom, third-party, or foreign connectors installed (for example, with fax services), ensure that they can be reinstalled on 2016 Exchange servers.
1 | Get-ReceiveConnector -Server <ServerToDecommission> |
Tip: Check the SMTP logs to see if any outside systems are still sending SMTP traffic to the servers via hard coded names or IP addresses. To enable logging, review Configure Protocol Logging. Also, ensure we have “time coverage” for any apps relaying weekly/monthly emails that may not be caught in a small sample size of SMTP Protocol logs. There is a great script available here that can help find any applications that may be relaying off your legacy environment.
In general, the decommissioning process is a great time to audit your mail flow configuration to ensure that all the connectors are properly configured and secured. Maybe it’s time to get rid of any of those Anonymous Relay connectors that may be in use in your environment. Or, if Hybrid, possibly relay against Office 365.
Exchange 2010 base transport rules are held in a different AD container than Exchange 2013 and newer rules. When installing Exchange 2016 in your environment it will import those Exchange 2010 based rules. However, any changes to Exchange 2010 rules after a later version of Exchange is installed must also be applied to your Exchange 2016 rules. This is further explained here under section Coexistence with Exchange 2010.
Run the following command to get all your Exchange Transport Rules. Must be run on Exchange 2016 to see all rules.
1 | Get-TransportRule | Select Name,RuleVersion |
Compare the rules with RuleVersion of 14.X.X.X to those with 15.1.X.X. If any Exchange 2010 rules don’t exist on Exchange 2016, they must be created. Also review all settings of each Exchange 2010 rule and replicate them to Exchange 2016.
Decommissioning Exchange 2010 cannot be initiated until all mailboxes have been moved to Exchange 2016. As an example, we cannot decommission Exchange 2010 Hub Transport servers completely until all of the mailboxes are moved off the legacy platform, this is due to how Delivery Groups are handled.
We encourage using the newest Exchange platform to process any move requests. If moving to Exchange 2016, move all mailboxes via Exchange 2016. Also, ensure that once all moves are completed, and that all associated Move Requests are removed as well. Any lingering move requests or mailboxes will prevent uninstallation of Exchange 2010.
To move all user mailboxes, run the following command to identify the mailboxes, and then plan to move them to the new platform.
1 | Get-MailboxDatabase -Server <ServerToDecommission> | Get-Mailbox |
Tip: Ensure that Archives are included with “Get-Mailbox -Archive” if you used Exchange Archives in 2010. Also, do not forget about your Discovery Search mailboxes – these can be found with: Get-Mailbox -Filter { RecipientTypeDetails -eq “DiscoveryMailbox”}. These will need to be moved (if they haven’t yet already), to Exchange 2016 as well.
It’s necessary to move the arbitration mailboxes from Exchange 2010 to 2016 for many Exchange Services to work properly, including the Exchange Admin Center (EAC). This is typically executed when Exchange 2016 is first installed, however, if that was missed, we will ensure that is handled now. The process to move is defined at: Move the Exchange 2010 system mailbox to Exchange 2013+. To verify which system mailboxes are located on 2010, use PowerShell on your Exchange 2010 server with the following example:
1 | Set-ADServerSettings -ViewEntireForest $true Get-MailboxDatabase -Server <ServerToDecommission> | Get-Mailbox -Arbitration |
Note: If any mailboxes are present, move them to an Exchange 2016 database.
Installing first Exchange Server 2013+ into Exchange 2010 organization creates a new OAB. It also marks the new OAB as default. The Exchange 2010 OAB is not used by Exchange 2013+ servers so moving the OAB is not necessary. Move the OAB to another Exchange 2010 server, if you are removing an Exchange 2010 server that’s currently hosting the OAB, and there are other Exchange 2010 servers in the org. If you are removing the last Exchange 2010 server in the org, remove the OAB.
Verify that all the public folders have been migrated to Exchange Online, Office 365 Groups, or Exchange Modern public folders.
If the following is true:
In that case, you may need to run the SetMailPublicFolderExternalAddress.ps1 script to ensure Exchange 2013+ servers can continue sending emails to Exchange Online MEPFs.
Assuming best practices were followed for the Exchange 2010 environment, we will have a DAG for HA/DR capabilities. Now that all mailboxes have been removed from the 2010 environment, we are ready to tear down this DAG to move forward with decommissioning Exchange 2010.
First, we start with the copies. For every mailbox database copy in the environment hosted on Exchange 2010, we will need to remove the Mailbox Database Copy. This can be done via the UI, or via PowerShell:
1 | Remove-MailboxDatabaseCopy -Identity <DatabaseName>\<ServerToDecommission> -Confirm:$False |
NOTE: Removing the copy will not remove the actual .edb database file from the Server.
For each Exchange 2010 server in the environment, we will need to remove the individual server from the DAG. This is evicting the server from the cluster. This can be done via the UI, or through PowerShell.
1 | Remove-DatabaseAvailabilityGroupServer -Identity <DAGName> -MailboxServer <ServerToDecommission> |
Lastly, once the Database copies are removed, and the servers are evicted from the cluster, the last thing is to finally remove the DAG from the environment. This can be done with the following PowerShell command:
1 | Remove-DatabaseAvailabilityGroup -Identity <DAGName> -Confirm:$False |
Tip: If you have an even-membered DAG, and leveraged a File Share Witness, don’t forget to decommission the file share witness that was used for the Exchange 2010 DAG.
Configuration steps are required to move Exchange 2010 UM to Exchange 2016 servers. The following link can be used to guide through removal of UM from Exchange 2010. If moving to a third-party UM solution, remove the UM components to allow un-installation of the UM role.
If you have an Edge server, you will need to install Exchange 2016 Edge and recreate the Edge Subscription on the E2016 server. This is further documented here.
As mentioned in the beginning of the document, due to so many different types of deployments and configurations, it’s difficult to cover all scenarios however it’s recommended to check any other possible scenarios that apply to your environment.
Make a list of applications that may be using Exchange 2010 (e.g. EWS, mail transport, database-aware) and make sure to configure these applications to start using Exchange 2016 infrastructure.
Test shutting down the Exchange servers for a few days to a few weeks to see if there are any issues. You are auditing for any applications that are trying to connect to the Exchange 2010 servers or trying to send email through the Exchange 2010 servers. Enabling protocol logging on the Hub Transport roles prior to shutting down the servers is an option. That way if any mail is processing through these servers, upon restart, the logging will begin immediately. If applications or servers are trying to connect you can remediate those or power on the Exchange 2010 servers until remediation can happen.
Tip: Check Active Directory DNS Zone settings to see if DNS Scavenging is enabled. If this is enabled, the DNS record could become stale during the shutdown time frame and cause DNS issues for the Exchange 2010 server.
As you begin the process of removing servers, you should go through the list below and ensure you have everything tested and ready to go.
Remove Any Exchange 2010 Client Access Arrays from Active Directory and DNS. Refer to the following document to remove the Client Access Array object with Shell using the following example:
1 | Remove-ClientAccessArray -Identity casarray01.contoso.com |
Be sure to also remove any references in DNS to the CAS Array Name.
If you followed either the Best practices for Migrations blog or the Coexistence with Kerberos blog, we recommend that any old alternate service accounts (ASAs) used for E2010 be removed. If you are using a different namespace than Exchange 2016, please verify old SPNs are also removed.
Use the following command to remove Exchange 2010 OAB:
1 | Get-OfflineAddressBook | ?{$_.ExchangeVersion -like "*14*"} | Remove-OfflineAddressBookMailbox |
Now that all mailboxes are migrated from the Exchange 2010 platform, and the DAG is properly removed, we will want to decommission any leftover databases from the Exchange 2010 environment. To remove all Exchange 2010 databases, review the output of the following, and remove individually:
1 | Get-MailboxDatabase -Server <ServerToDecommission> |
And then remove the database with:
1 | Remove-MailboxDatabase -Identity DB1 |
NOTE: If there are any mailboxes currently residing on the database, we will not let you remove the database, it will fail with the following error:
If you chose not to migrate public folders, refer to the following document to remove public folders with either EMC or Shell using the following example:
Refer to the following document to remove the public folder databases with PowerShell using the following example:
1 | Remove-PublicFolderDatabase -Identity "PFDB01" |
Tip: Remember the .edb files linger after the above is done. Feel free to delete, backup, or do with these as you please.
It’s recommended to uninstall in the following order: CAS, Hub, UM (if any), then Mailbox.
When you begin the uninstall process, close EMC, EMS, and any additional programs that could delay uninstall process (i.e. programs using .NET assemblies; antivirus and backup agents are examples). You can either run Exchange 2010 Setup.exe or navigate to Control Panel to modify or remove Exchange 2010 (either server roles or the entire installation). Specific steps are discussed in Modify or Remove Exchange 2010.
Tip: Exchange will protect itself! If you properly uninstall via Add/Remove Programs, it will ensure that it is ready to be uninstalled via Readiness Checks! If all the above prep work is completed before hand, it should uninstall just fine.
After uninstalling Exchange there will be some general “housekeeping” tasks. These may vary depending on the steps taken during your upgrade and depending on your organization’s operational requirements.
Examples include:
With the uninstall of the last server, hopefully Exchange 2010 treated your organization well. The Exchange product team takes great pride of the success of the platform and hope that you see the same success with Exchange 2016 (or Exchange Online!). Messaging sure has come a long way since it was released way back in 2009.
REFERENCES
Exchange Team Blog article on Decommissioning Exchange 2010 On-Premises
Today Microsoft is announcing the availability of quarterly servicing cumulative updates for Exchange Server 2016 and 2019. These updates include fixes for customer reported issues as well as all previously released security updates.
Personal Note: I was recently involved in a layoff at Microsoft in the Vendor PFE world. I am currently looking for new engagements.
This quarterly Exchange release includes an important update to the Exchange 2019 Sizing Calculator. We’ve made improvements to the logic to detect whether a design is bound by mailbox size (capacity) or throughput (IOPs) which affects the maximum number of mailboxes a database will support. Previous versions of the calculator produced incorrect results in some situations.
The Exchange team highly recommends using calculator version 10.4, included with the March 2020 quarterly CU release, to size Exchange Server 2019 deployments.
Cumulative Update 5 for Exchange Server 2019 also fixes an issue that can happen when you use the Manage-MetaCacheDatabase.ps1 script to enable MetaCacheDatabase (MCDB).
This issue occurred because of a change in behavior in Windows Server 2019 that caused Get-Disk to return all uninitialized discs within the Database Availability Group (DAG) or cluster. The script then incorrectly tried to format an SSD on another DAG member. We documented a workaround for CU4 here, but we’ve fixed it in CU5.
Cumulative Update 5 for Exchange Server 2019 is also required to fix a known issue with partial word searches when the client is using Outlook in online mode.
The KB articles that describe the fixes in each release and product downloads are available as follows:
Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate documentation.
Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.
Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the currently supported cumulative update for the product version in use, e.g.,
2013 Cumulative Update 23
2016 Cumulative Update 16 or 15
2019 Cumulative Update 5 or 4.
For the latest information on Exchange Server and product announcements please see:
What’s New in Exchange Server and Exchange Server Release Notes.
I had a failure on one of my two Exchange 2019 CU4 servers when installing the Security Update for them:
I could not restart the install as it would fail when getting to the services stoppage part of the installation. I saw this error in the ServiceControl.log file in the C:\ExchangeSetupLogs Directory
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | [20:19:52] ----------------------------------------------- [20:19:52] * ServiceControl.ps1: 3/11/2020 8:19:52 PM [20:19:52] Performing service control with options: [20:19:55] Saving service and registry data [20:19:55] State file C:\ExchangeSetupLogs\ServiceState.xml already exists. [20:19:55] Overwrite is specified. File C:\ExchangeSetupLogs\ServiceState.xml is going to be overwritten with a new state. [20:19:55] Saving service state to 'C:\ExchangeSetupLogs\ServiceState.xml'... [20:20:01] State file C:\ExchangeSetupLogs\ServiceStartupMode.xml already exists. [20:20:01] Overwrite is specified. File C:\ExchangeSetupLogs\ServiceStartupMode.xml is going to be overwritten with a new state. [20:20:01] Saving services startup mode. [20:20:01] Adding to installed roles list: AdminTools [20:20:01] Adding to installed roles list: ClientAccessMailboxRole [20:20:01] Adding to installed roles list: Mailbox [20:20:01] Adding to installed roles list: Bridgehead [20:20:01] Adding to installed roles list: Mailbox [20:20:01] Stopping services for the following roles: AdminTools ClientAccess FrontendTransport Bridgehead Mailbox [20:20:01] Stopping services for 'AdminTools ClientAccess FrontendTransport Bridgehead Mailbox'... [20:20:01] [Error] System.ArgumentNullException: Value cannot be null. Parameter name: array at System.Array.Reverse(Array array) at CallSite.Target(Closure , CallSite , Type , Object ) [20:41:36] ----------------------------------------------- |
I had searched around based on the error code 0x80070643 and found these answers that some had used to get the installation to work.
I downloaded the .msp file to install manually and read the answers on the web-page. It was said that there was an issue with the ServiceControl.ps1 file that is in the Exchange Server BIN directory when running Patch with the Verbose logging enabled:
1 2 3 4 5 6 7 8 9 10 11 | MSI (s) (E8:68) [10:09:37:577]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI347C.tmp, Entrypoint: CAQuietExec MSI (s) (E8!D0) [10:09:37:583]: PROPERTY CHANGE: Deleting QtExecCmdLine property. Its current value is '"E:\Exchange 2019\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -command . 'E:\Exchange 2019\\bin\servicecontrol.ps1'BeforePatch"'. CAQuietExec: Error 0x80070001: Command line returned an error. CAQuietExec: Error 0x80070001: CAQuietExec Failed CustomAction CA_SAVEDATA_STOP_SERVICES returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 10:09:40: CA_SAVEDATA_STOP_SERVICES. Return value 3. |
I kept reading and digging into the fix for the file. It was said to modify a number of lines in the ServiceControl.ps1 script:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | In the lines of the script (876 and 885), it was: 876: add-pssnapin -Name Microsoft.Exchange.Management.Powershell.Setup -ea SilentlyContinue 885: remove-pssnapin -Name Microsoft.Exchange.Management.Powershell.Setup I changed the lines to say "Microsoft.Exchange.Management.Powershell.Support" instead of "Microsoft.Exchange.Management.Powershell.Setup": 876: add-pssnapin -Name Microsoft.Exchange.Management.Powershell.Support -ea SilentlyContinue 885: remove-pssnapin -Name Microsoft.Exchange.Management.Powershell.Support Also, there was an error referencing the script's inability to stop the WMI service without the -Force flag, so I changed that as well. (Line 342) 342: Stop-SetupService -ServiceName $servicename -ev script:servicecontrolerror -force 3. Next, Change all the Stop-SetupService Entries in the script to Stop-Service 4. Next, Change all the Start-SetupService to Start-Service 5. Next, Add the following to StopServices function to bypass the attempt that was trying to stop services, because they have already been stopped ... Start at line 300 300: Status "Stopping services for '$Roles'..." 301: $services = Get-ServiceToControl $Roles -Active 302: ##Change Here 303: if ($services -eq $null) { 304: return $true 305: } 306: ##End Change Here 307: [array]::Reverse($services) 6. I noticed that these 2 files ServiceStartupMode.xml and ServiceState.xml may have permission issue since the last failure in the C:\ExchangeSetupLogs directory. So, I also renamed the files to .old |
Once I made those changes. I renamed the original ServiceContol.ps1 to a .old file and saved this modified file to the BIN directory. I was then able to successfully run the Security Update.
Both are CU4, but the server that failed had been upgraded from CU1 where the one that did NOT fail was a clean installation of CU4. So, I checked the ServiceConrol.ps1 file on both servers:
I have not tested this, but maybe if I had copied the ServiceControl.ps1 file from the CU4 clean installation to the original install, the script might have worked since the creation dates are different and I have no other version information to go on. I will verify this though. For now, the changes to the script allowed me to successfully install the Security Update Successfully.
NOTE: All the Exchange and IIS Services were in a Startup Mode: Disabled state and I had to reset them ALL to Automatic. Once that was completed and the server rebooted, Exchange was returned to normal state. ****Also, just to be safe, I ran a great script that assures the server is out of maintenance mode. You can get the script HERE. You can also get the script to put the server into maintenance mode. You can get the script HERE. These scripts will work on Exchange 2013 and above servers.
Something was still wrong with the server. ActiveSync and PAM started breaking. I started having all sorts of authentication problems. I decided to restore the server from backup from Tuesday. I forgot to backup the ServiceControl.ps1 file that modified, but I moved the one from the successful installation to the restored server and am currently running the update. I will see if it works and send the information to you.
The restore worked great and placing the ServiceControl.ps1 file in the BIN directory on the prior failed Exchange Server did allow for the installation to complete successfully. I have tested ActiveSync and Authentication which is now functioning properly. Hooray!
REFERENCES:
Exchange Server Security Update fails with 0x80070643
Exchange Maintenance Mode Script (Start)
Exchange Maintenance Mode Script (Stop)
Exchange Server 2019 CU4 Security Update
In my role as a PFE for Microsoft, I have been going through many deployments of Exchange 2016 from Exchange 2010 due to the end of life deadline for Exchange 2010. I am actually in the middle of three enterprise level deployments this month.
Because of this, I wanted to provide some MUST READ links with consideration to the Exchange 2016 Deployment process. Please click on the links below, and they will take you to the documentation needed when preparing for a Exchange 2016 migration and deployment from Exchange 2010.
IMPORTANT READ:
Exchange On-Premises Best Practices for migration from Exchange 2010 to Exchange 2016 (Lots of important links and articles within this document!)
Other relevant articles:
Exchange 2016 System Requirements
Exchange Deployment Site Consideration
What changes in AD when Exchange 2016 is installed
Exchange 2016 Schema Changes to AD
Exchange Server Virtualization
Exchange Server Preferred Architecture
Load Balancing in Exchange Server
Load Balancing Exchange 2016 In Depth
Hybrid Considerations:
Decommissioning Exchange 2010 servers in a Hybrid Deployment
How and when to decommission On-Prem Exchange Hybrid Servers
Hybrid Deployment Prerequisites
I will add more articles as they become relevant in my experiences with my customers and feel they could be relevant here as well. If you have a suggestion for a link that should be considered added to this post, feel free to leave a comment!
During my time as a PFE for Microsoft, I have encounted many issues with Federation in a Hybrid Exchange Deployment. Recently, the following support announcement came out and I wanted to share as I hope this can help others that may be having issues out there.
One of the more common causes of HCW failures is the Federation Trust step for the Exchange on-premises organizations in Full hybrid configurations (Classic or Modern topologies).
Federation trust is a mandatory step in the on-premises Exchange organizations when configuring Full hybrid deployments, as this allows us to create organization relationships (for features like hybrid free/busy or OWA/EAS redirection) and sharing policies (1:1 hybrid calendar sharing). In Exchange Online multi-tenant organizations, federation trust is already in place.
Below is an illustration of an Exchange hybrid deployment where both the Exchange on-premises organization and the Exchange Online organization have a trust with Azure Authentication System (formerly called Microsoft Federation Gateway):
Before getting to our subject, let’s quickly go over different hybrid configurations and Hybrid Configuration Wizard (HCW) – as this is the supported tool to configure hybrid deployments.
There are 2 flavors of hybrid configurations:
• Classic hybrid
• Modern hybrid
At this time, each of those supports the following hybrid modes:
A quick overview of Full / Minimal / Express options, can be found here. More info on HCW is here.
As mentioned earlier, a federation trust is created by HCW only in Full Hybrid.
HCW logs are located at %appdata%\Microsoft\Exchange Hybrid Configuration on the machine from where HCW was ran. The easiest way to get to them is to press F12 in the HCW window to open the Diagnostic tools and from there you can Open Folder Logging or Open Log File directly.
When you have issues with federation trust, the log will usually show errors when one of the following cmdlets are executed:
Set-FederationOrganizationIdentifier
or
Add-FederatedDomain (but can be other cmdlets as well).
Once you identified the exact cmdlet failing and where (Session=OnPremises – means Exchange Management Shell and Session=Tenant means Exchange Online PowerShell), you should copy-paste the failing command and try to execute it manually and see if that is failing as well (most likely it will). You can also open the shells from F12 Diagnostic tools windows in HCW.
In order to get more details on the error and to rule out this is not an issue with HCW itself, you will need to separately run the same command that threw exception in HCW log and add Verbose switch to get verbose details of the error and the serialized remote exception.
For example, if the Exchange server version is Exchange 2010, you will run the failing command with Verbose switch in Exchange Management Shell (EMS), see if that fails and then get the serialized remote exception.
Example:
1 2 3 4 5 6 7 8 9 10 11 12 13 | start-transcript Set-FederatedOrganizationIdentifier -AccountNamespace <contoso.com> -DelegationFederationTrust 'Microsoft Federation Gateway' -Enabled:$true -VERBOSE $Error[0].Exception |fl -f $Error[0].Exception.SerializedRemoteException |fl –f Get-FederatedOrganizationIdentifier |FL Get-FederationTrust |FL stop-transcript |
If the Exchange Server version is Exchange 2013/2016 and the above commands didn’t show more details on the error, we can also try the following:
Example:
1 2 3 4 5 6 7 8 9 10 11 12 13 | start-transcript Set-FederatedOrganizationIdentifier -AccountNamespace <contoso.com> -DelegationFederationTrust 'Microsoft Federation Gateway' -Enabled:$true -DefaultDomain $null -VERBOSE $Error[0].Exception |fl -f $Error[0].Exception.SerializedRemoteException |fl –f Get-FederatedOrganizationIdentifier |FL Get-FederationTrust |FL stop-transcript |
Once you’ve gathered the verbose error / serialized exception, try to understand where it is failing (or provide it to Microsoft Support together with the HCW log).
This is a known old issue on Exchange 2016 CU7 servers, make sure your Exchange servers are updated to the latest CU.
Full error in the HCW log:
1 2 3 | 2017.10.06 01:45:56.562 *ERROR* 10277 [Client=UX, Activity=Domain Ownership, Session=OnPremises, Cmdlet=Set-FederatedOrganizationIdentifier, Thread=21] FINISH Time=398.4ms Results=PowerShell failed to invoke 'Set-FederatedOrganizationIdentifier': Object reference not set to an instance of an object. An unexpected error has occurred and a Watson dump is being generated: Object reference not set to an instance of an object. 2017.10.06 01:45:56.563 *ERROR* 10224 [Client=UX, Page=DomainProof, Thread=21] Microsoft.Online.CSE.Hybrid.PowerShell.PowerShellInvokeException: PowerShell failed to invoke 'Set-FederatedOrganizationIdentifier': Object reference not set to an instance of an object. An unexpected error has occurred and a Watson dump is being generated: Object reference not set to an instance of an object. ---> System.Management.Automation.RemoteException: Object reference not set to an instance of an object. |
Resolution: Install the latest CU for Exchange 2016
Full error in the HCW log:
1 2 3 | 2019.07.16 17:53:14.750 10276 [Client=UX, Activity=Domain Ownership, Session=OnPremises, Cmdlet=Add-FederatedDomain, Thread=19] START Add-FederatedDomain -DomainName 'contoso.com' 2019.07.06 17:53:15.375 10177 [Client=UX, Activity=Domain Ownership, Provider=OnPremises, Thread=19] PowerShell Error Record: {CategoryInfo={Activity=Add-FederatedDomain,Category=InvalidResult,Reason=DomainProofOwnershipException,TargetName=,TargetType=},ErrorDetails=,Exception=Proof of domain ownership has failed. Make sure that the TXT record for the specified domain is available in DNS. The format of the TXT record should be "example.com IN TXT hash-value" where "example.com" is the domain you want to configure for Federation and "hash-value" is the proof value generated with "Get-FederatedDomainProof -DomainName example.com".,FullyQualifiedErrorId=367408EF,Microsoft.Exchange.Management.SystemConfigurationTasks.AddFederatedDomain} |
Resolution:
• Check the TXT record for your domain(s) in HCW log or in Exchange Management Shell with command Get-FederatedDomainProof -DomainName
• See if it matches your published TXT record with either nslookup utility or by checking internet websites like https://www.whatsmydns.net/ put your domain in hostnames, type=txt, Nameservers – Authoritative
You would look for errors, missing records or unusual formatting (characters, spaces, quotes, TXT record split in half).
Full error in the HCW log:
1 | 2018.10.10 17:03:31.277 *ERROR* [Activity=Domain Ownership, Session=OnPremises, Cmdlet=Set-FederatedOrganizationIdentifier] FINISH Time=64.3s Results=PowerShell failed to invoke 'Set-FederatedOrganizationIdentifier': An error occurred while attempting to provision Exchange to the Partner STS. Detailed Information "An error occurred accessing Windows Live. Detailed information: "The underlying connection was closed: An unexpected error occurred on a receive.".". |
Resolution:
Check outbound access from all your Exchange Servers to Microsoft Federation Gateway by browsing using Internet Explorer with PSEXEC tool (with -s and -i switches) from the Exchange Server (this will use Internet Explorer under System Account / Exchange Server Account).
In this example, “Windows Live” is actually this exact URL: https://domains.live.com/service/managedelegation2.asmx
From on-premises Exchange to Office 365, the Exchange 2010 MBX & CAS or 2013 MBX (backend) or 2016 / 2019 would need outbound Internet access to the Microsoft Federation Gateway in addition to https://outlook.office365.com/ews/exchange.asmx
Verify the machine/system account can access these Microsoft Federation Gateway URLs:
For a complete list of O365 URL & IP addresses, see these articles:
Note: If the Exchange requires a proxy server to access the Internet, specify the proxy server using “Set-ExchangeServer myExchange01 -InternetWebProxy http://myproxy:80”. Notice such proxy can’t require any user authentication for outbound Internet access, and the proxy must start with HTTP: and not HTTPS: (secure SSL).
You can also set the proxy using netsh as well.
set proxy proxy-server=”http=myproxy;https=sproxy:88″ bypass-list=”*.contoso.com”
In rare instances, you can use the machine/system account to access the URLs from the browser, but Exchange cmdlets still failed with “Could not establish trust relationship for the SSL/TLS secure channel.” If that happens, make sure the certificate authorities for the urls are installed at the Third-Party Root Certification Authorities of the machine local certificate location.
REFERENCE:
Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)
Firewall Considerations for Federated Delegation
Federated delegation features require that the Mailbox and Client Access servers in your organization have outbound access to the Internet by using HTTPS. You must allow outbound HTTPS access (port 443 for TCP) from all Exchange 2010 Mailbox and Client Access servers in the organization.
Full error in the HCW log:
1 2 | 2019.02.14 12:56:21.658 [Activity=Domain Ownership, Session=OnPremises, Cmdlet=Get-FederatedOrganizationIdentifier] FINISH Time=133.0ms Results=1 FederatedOrganizationIdWithDomainStatus {AccountNamespace='FYDIBOHF25SPDLT.contoso.com' DelegationTrustLink='contoso.local/Configuration/Deleted Objects/Microsoft Federation Gateway DEL:8e834abf-5154-4540-a3c6-5a5c614c6a06'Enabled=1 ExchangeVersion='0.10 (14.0.100.0)' Guid=2e1da884-9686-4221-8098-d34ced5a2f85 Id='Federation' Identity='Federation' IsValid=1 Name='Federation' ObjectState='Unchanged' WhenChanged='8/11/2015 5:35:58 PM' WhenChangedUTC='8/11/2015 2:35:58 PM' WhenCreated='10/18/2009 10:30:09 AM' WhenCreatedUTC='10/18/2009 6:30:09 AM'} 2019.02.14 12:56:21.677 [Client=UX, Page=DomainProof] Unproven Domains: 1 |
Resolution:
Look for orphaned federation trust:
Get-FederatedOrganizationIdentifier | FL
or
in HCW log if you see something with “DEL“: “contoso.com/Configuration/Deleted Objects/Microsoft Federation Gateway/DEL: <xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx>”.
Solution is to remove the orphaned federation trust and re-run HCW.
Reference here.
NOTE: as a first step, you can try to run the command remove-federateddomain with the switch -Force. Also, you don’t need to recreate federation trust manually, just re-run HCW (this will recreate federation trust for us)
Full error in the HCW log:
1 2 3 | 2019.08.23 07:45:22.914 10276 [Client=UX, Activity=Domain Ownership, Session=OnPremises, Cmdlet=Set-FederatedOrganizationIdentifier, Thread=20] START Set-FederatedOrganizationIdentifier -AccountNamespace 'contoso.com' -DelegationFederationTrust 'Microsoft Federation Gateway' -Enabled: $true -DefaultDomain $null 2019.08.23 07:45:23.239 *ERROR* 10277 [Client=UX, Activity=Domain Ownership, Session=OnPremises, Cmdlet=Set-FederatedOrganizationIdentifier, Thread=20] FINISH Time=325.0ms Results=PowerShell failed to invoke 'Set-FederatedOrganizationIdentifier': An error occurred while attempting to provision Exchange to the Partner STS. Detailed Information "An unexpected result was received from Windows Live. Detailed information: "InternalError InternalError: Internal error.".". {CategoryInfo={Activity=[System.String] Set-FederatedOrganizationIdentifier,Category=[System.Management.Automation.ErrorCategory] InvalidResult,Reason=[System.String] |
Resolution:
Open request with Microsoft Support or check if any Service Incident is published. Please see this for more information.
Full error in the HCW log:
1 | Set-FederatedOrganizationIdentifier,Category=[System.Management.Automation.ErrorCategory] InvalidResult,Reason=[System.String] ProvisioningFederatedExchangeException,TargetName=[System.String] ,TargetType=[System.String] },ErrorDetails=,Exception=[System.Management.Automation.RemoteException] An error occurred while attempting to provision Exchange to the Partner STS. Detailed Information "An unexpected result was received from Windows Live. Detailed information: "1007 AccessDenied: Access Denied."." |
Resolution:
“1007 Access Denied” error is usually when we have issues with:
If the federation trust certificate is not found on any of the servers, then proceed with resolution from the next error.
As an example, from one HCW log, there seems to be this federation trust certificate expired on 05/13/2019:
1 | OrgCertificate=[Subject] CN=Federation [Issuer] CN=Federation [Serial Number] 4E91XXXXXXXXXXXXXXXXXXXXXXXXXXXX [Not Before] 5/13/2014 11:21:36 AM [Not After] 5/13/2019 11:21:36 AM |
Full error in the HCW log:
1 | 2019.11.22 14:40:32.569 *ERROR* 10277 [Client=UX, Activity=Domain Ownership, Session=OnPremises, Cmdlet=Get-FederatedDomainProof, Thread=6] FINISH Time=125.1ms Results=PowerShell failed to invoke Get-FederatedDomainProof: Federation certificate with the thumbprint ‘03650FFAF05E83E3B007DF3473CB5753F5C4459’cannot be found. |
Resolution:
Follow the procedure here to manually cleanup the federation trust from AD. Once this is done, re-run the HCW to re-create it automatically.
REFERENCE:
How To Address Federation Trust Issues using the Hybrid Configuration Wizard
When you deploy or upgrade to Microsoft Exchange 2019 Cumulative Update 4 (CU4) on Microsoft Windows Server 2019 or Windows 10 (Management Tools only) builds 1909 or 1903, the system prerequisites check fails, and you receive the following error message:
“This computer requires .NET Framework 4.8 (https://support.microsoft.com/kb/4503548).”
By default, Windows builds 1909 and 1903 already have .NET Framework 4.8 installed. When you try to reinstall the software, the installation fails.
This problem is caused by a prerequisite check that was introduced in Cumulative Update 4. This process checks incorrectly for .NET Framework 4.8. Because the prerequisite check doesn’t recognize that .NET Framework 4.8 is already installed.
Microsoft is researching this problem and will post more information in this article when it becomes available.
Important
Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you modify it, back up the registry for restoration in case problems occur.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
Name: Release
Type: REG_DWORD
Data: 528040 (decimal)
Change the Data value to 528049 (decimal)
This should allow everything to run correctly after the installation.
REFERENCES
Exchange CU4 Prerequisite Check Fails for .NET 4.8 for Windows Server builds 1909 and 1903
I have run into this issue at a number of my customers that utilize an Exchange Edge Server in their Hybrid Deployment. They’ll need to modify their send connectors for their forced TLS communication with their partners or own mailboxes in Office365. Whenever they want to modify the send connector and save the changes, they get the following error messages:
“PowerShell failed to invoke ‘Set-SendConnector’: Error 0x5 (Access is denied) from cli_GetCertificate”
or
“Error 0x6ba (the RPC server is unavailable) from cli_GetCertificate”
This issue occurs after you install the Cumulative Update 14 for Exchange Server 2016, Cumulative Update 13 for Exchange Server 2016, or Cumulative Update 23 for Exchange Server 2013.
This issue occurs because the TLS certificate check (in case the TlsCertificateName attribute is populated on the send connector) doesn’t work against the Edge servers as the RPC communication is blocked against the Edge servers.
Now the current workaround for this has been to delete the Edge Send Connector and recreate the connector from scratch via PowerShell with all the settings and changes entered. This is not a viable solution especially if your communications with your partners change constantly and changes are made to the secure communications channel between you and them.
To fix this issue, install one of the following updates:
For Exchange Server 2019, install the Cumulative Update 4 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019.
For Exchange Server 2016, install the Cumulative Update 15 for Exchange Server 2016 or a later cumulative update for Exchange Server 2016.
For Exchange Server 2013, there is no fix at this time. My personal recommendation is to plan an upgrade to Exchange 2019.
REFERENCES
Set-SendConnector doesn’t work for Exchange Server in hybrid scenarios with Edge Server installed
Support Announcement:
Released: December 2019 Quarterly Exchange Updates
Release Date: December 17, 2019
Summary
Today Microsoft is announcing the availability of quarterly servicing cumulative updates for Exchange Server 2016 and 2019. These updates include fixes for customer reported issues as well as all previously released security updates.
Setup Now Requires .NET Framework 4.8
As previously announced .NET 4.8 is now required and enforced by setup with the updates released today.
Calculator Updates
Cumulative Update 4 includes a significant update to the Exchange 2019 sizing calculator. After the initial re-work and optimization for Exchange 2019 previously delivered, we’ve updated some formulas based upon new Big Funnel performance data gathered from the O365 service and real-world customer experiences. Version 10.3 of the calculator includes improvements to calculations and default settings which allow for better and smoother utilization of disk resources. We’ve received feedback from customers that they’d like more information on constraints which impact system design, specifically disk resources. Included in this update, is an indication on the Input worksheet will provide information as to whether the design is constrained by IOPs throughput or disk capacity.
We’ve added additional explanatory messages when the calculator detects a setting conflict, made additional improvements in input performance and improved support for using manual/override configurations. The Volume Design sheet had a complete re-work to improve the presentation and accuracy of the information being displayed to support these changes. All-in-all, this version of the calculator provides the best possible experience to plan your Exchange 2019 deployment and replaces all previous releases.
Address Book Policy Changes
When organizations deploy Address Book Policies to users they can sometimes hit an issue when a locally logged in user without a mailbox tries to open a mailbox linked to another user account using Outlook. This conflict results in ABP’s being inconsistently applied. The updates released today contain a change detailed in KB4532747 which resolves this issue and ensures the ABP’s assigned to the mailbox being opened are always used.
Release Details
The KB articles that describe the fixes in each release and product downloads are available as follows:
• Exchange Server 2019 Cumulative Update 4 (KB4522149), VLSC Download
• Exchange Server 2016 Cumulative Update 15 (KB4522150), Download
Additional Information
Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate documentation. Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed.
To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.
Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the currently supported cumulative update for the product version in use, e.g., 2013 Cumulative Update 23; 2016 Cumulative Update 15 or 14; 2019 Cumulative Update 4 or 3.
For the latest information on Exchange Server and product announcements please see What’s New in Exchange Server and Exchange Server Release Notes.
Note: Documentation may not be fully available at the time this post is published. Article Link
My continuation of the “Installation from HELL” proceeded onward today with our team attempting to install Exchange on another server in the test environment and having it fail when getting to the Mailbox Role portion of the installation.
The error kept saying that the installation was failing due to a “Database is mandatory on UserMailbox”. We had been having many issues with the Schema and RBAC roles which were resolved in my other post by adding the Role Assignments to the schema. I did mention that the environment started settling down and the system mailboxes (Arbitration) along with the Health Mailboxes started functioning. This was actually not the case for the Arbitration mailboxes. I glanced at the following article to see how to manually recreate the Arbitration mailboxes again.
I performed a “Get-Mailbox -Arbitration | fl Name” in Exchange Powershell (similar to the screenshot below) to see if the mailboxes were in fact created. They in fact were not and were giving the error “Database is mandatory for the UserMailbox.”
So, I tried to do what the original article said to do and enable the mailboxes one by one. I kept getting errors when trying to create the mailboxes. So I began to search the internet for another way to possibly remediate this without having to get too deep into the system.
I found the following article explaining the exact error I was getting during the installation of Exchange. In the article, it said to look at the attributes of the account associated with the Arbitration mailbox to see if the homeMDB attribute had no value:
Now, since I was NOT having good luck with either the Exchange Setup nor PowerShell, I had to figure out a way to place the attribute value so that the mailbox would be visible. What I did was this:
Once completed with remediating the attribute for all the Arbitration mailbox accounts missing the value, I re-ran the cmdlet to verify that the error was not present for any arbitration maibox:
I then uninstalled and re-installed Exchange using setup on the failing server and the installation completed successfully.
This has been an excellent week in training on the value of the setup process for Exchange and also the value of the system accounts and values in relation to Exchange and it working properly.
REFERENCES:
Exchange Install Error Database is mandatory on UserMailbox
Recreate missing arbitration mailboxes
I had a very interesting installation issue recently when installing Exchange 2019 into a new environment. We ran through all the Exchange Preparation for the root and child domains in the forest as described HERE. The results of those installation procedures showed SUCCESS, but when we started installing Exchange, we ran into issues with the System Mailboxes not being available to complete the Mailbox Role part of the installation. Most of the articles that I found said to re-run the Domain Prep (/preparealldomains) and the AD Prep (/pad). So we did, and managed to get the first server installed somehow.
The reason I said somehow is because when we tried to logon to the EAC, we would get a 400 Bad Request Error and could not logon to the console. Next, we tried PowerShell and was able to load PowerShell, but I noticed that only ~100 cmdlets loaded. I thought that maybe we had to re-create the account mailbox to get it working properly. Problem was, one of the cmdlets that would not load was Disable-Mailbox along with others like Enable-Mailbox and New-Mailbox. It was as if the admin account we were using had no rights to administer Exchange in any way.
Next, we opened the mailbox in OWA. The mailbox came up okay, so I told the admin to change the URL to /ecp to try and get into the admin center. What happened was that the normal user control panel opened instead, showing again that the account did not have permissions.
We checked replication to the child domain and made sure there were not any apparent AD issues present. There were none. I next started reviewing how Exchange uses RBAC (Role Based Access Control) Groups and Role Assignments to grant users access to Exchange Admin Functionality. I read the following article located HERE.
Something told me to go and check the Schema again, so I went to ADSIEdit > Configuration Container > Services > Microsoft Exchange > (Organization Name) > RBAC > Role Assignments
I looked at the list of role assignments in the window as follows:
From the picture, you can see that the list is small, which in my experience is not correct. I verified this by going into my own 2019 environment and comparing the number of objects in that folder:
If you notice the list is MUCH longer and has many more objects listed in the container. So, how did Exchange Setup miss this during preparation? That I will find out later, but first I have to remediate this problem.
If the RBAC roles assignments are not installed to allow an account to have administrative privileges in Exchange, then you cannot administrate Exchange to even make the necessary changes! Especially so if you’ve only installed ONE server in the environment!
Manually repair the installation by running the script that creates these Objects in the Schema during setup.
******DISCLAIMER: Running the following commands in these instructions, running ADSIEdit, and/or making changes to your Schema and Exchange Installation outside the normal setup process is NOT recommended! Microsoft, LDLNET LLC, nor I (Lance Lingerfelt) are responsible for any issues or errors that may arise from using these instructions, period!******
That said, preform the following to regenerate the objects in the Schema:
1) Open Windows PowerShell (not the Exchange Management Shell) on the server that you installed Exchange Server on with the same account you used to install Exchange.
a. If you have UAC enabled, right click Windows PowerShell and click Run as administrator.
2) Run Start-Transcript c:\RBAC.txt and press Enter
a. This will start logging all commands and output you type to a text file.
3) Run Add-PSSnapin *setup and press Enter
a. This adds the setup snap-in which contains the setup cmdlets used by Exchange during install. You may see errors about loading a format data file. You can ignore those errors.
NOTE: DO NOT run any other cmdlets in this snap-in. Doing so could irreparably damage your Exchange installation.
4) Run Install-CannedRbacRoleAssignments -InvocationMode Install -Verbose and press Enter.
a. This cmdlet should create the required role assignments between the role groups and roles that should have been created during setup.
b. Be sure you run with the Verbose switch so we can capture what the cmdlet does.
5) Run Remove-PSSnapin *setup and press Enter
6) Run $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://servername/PowerShell/ -Authentication Kerberos and press Enter
a. Be sure to replace SERVERNAME with the FQDN of your server.
7) Run Import-PSSession $Session and press Enter
a. You should notice that the normal number of cmdlets load (~700)
8) Run Get-ManagementRoleAssignment and press Enter. If you are able to run the cmdlet, then the remedation worked.
9) Run Stop-Transcript and press Enter
The final check is to return to ADSIEdit and check the container and see if all the objects are there. We also were now able to get into EAC as well as saw that the Arbitration mailboxes were populating along with the Health Mailboxes as needed per the installation.
It was very neat to see how running the Add-PSSnapIn cmdlet opened all the scripts from the Exchange Setup and allowed me to manually fix the installation problem by running the cmdlet script that need to perform that task that setup missed or refused to run.
I am going to look over the installation logs and see where the installation failed and try to find out why it did not run on the subsequent re-installations of the AD Prep and Domain Prep. I will post those finding in this article when I have that available.
Thanks again to my Microsoft and Trimax teammates for your assistance with this. It has helped the customer in more ways than one!
I get asked this a lot in my travels, “What’s the difference with Exchange 2019 and why should we go to it other than the fact that it is the latest version released. I wanted to post my findings from articles that I found to help explain some of the improvements and differences with running Exchange 2019.
Exchange Server 2019 brings a new set of technologies, features, and services to Exchange Server, the messaging platform that provides email, scheduling, and tools for custom collaboration and messaging service applications.
There are some things that have been discontinued in Exchange 2019 which make the decision to go to it important for some companies.
| Feature | Comments and mitigation |
|---|---|
| Unified Messaging (UM) | Unified Messaging has been removed from Exchange 2019. We recommend that Exchange 2019 organizations transition to Skype for Business Cloud Voice Mail. |
This is a big deal for some companies as they rely on Unified Messaging to handle their Voice Messaging. There are some articles available to view to assist in transitioning from UM to the new voicemail features with O365. I will post them as I find them in this blog. Keep tuned in for updates!
Here are some other deprecated features:
| Client Access server role | The Client Access server role has been replaced by Client Access services that run on the Mailbox server role. The Mailbox server role now performs all functionality that was previously included with the Client Access server role. For more information about the new Mailbox server role, see Exchange Server architecture. |
| MAPI/CDO library | The MAPI/CDO library has been replaced by Exchange Web Services (EWS), Exchange ActiveSync (EAS), and Representational State Transfer (REST)* APIs. If an application uses the MAPI/CDO library, it needs to move to EWS, EAS, or the REST APIs to communicate with Exchange 2019. |
The following features are being de-emphasized in Exchange 2019 and may not be included in future versions of Exchange.
Today, CPU horsepower is significantly less expensive and is no longer a constraining factor. With that constraint lifted, the primary design goal for Exchange 2019 is for simplicity of scale, hardware utilization, and failure isolation. With Exchange 2019, we reduced the number of server roles to two: the Mailbox and Edge Transport server roles.
Unified Messaging (UM) has been removed from Exchange 2019. Other than that, the Mailbox server in Exchange 2019 includes all of the server components from the Exchange 2013 Mailbox and Client Access server roles:
The Edge Transport role is typically deployed in your perimeter network, outside your internal Active Directory forest, and is designed to minimize the attack surface of your Exchange deployment. By handling all Internet-facing mail flow, it also adds additional layers of message protection and security against viruses and spam, and can apply mail flow rules (also known as transport rules) to control message flow.
For more information about the Exchange 2019 architecture, see Exchange architecture.
Along with the new Mailbox role, Exchange 2019 now allows you to proxy traffic from Exchange 2013 Client Access servers to Exchange 2019 mailboxes. This new flexibility gives you more control in how you move to Exchange 2019 without having to worry about deploying enough front-end capacity to service new Exchange 2019 servers.
MAPI over HTTP is now the default protocol that Outlook uses to communicate with Exchange. MAPI over HTTP improves the reliability and stability of the Outlook and Exchange connections by moving the transport layer to the industry-standard HTTP model. This allows a higher level of visibility of transport errors and enhanced recoverability. Additional functionality includes support for an explicit pause-and-resume function, which enables supported clients to change networks or resume from hibernation while maintaining the same server context.
Note: MAPI over HTTP isn’t enabled in organizations where the following conditions are both true:
While MAPI over HTTP is now the default communication protocol between Outlook and Exchange, clients that don’t support it will fall back to Outlook Anywhere (RPC over HTTP).
Outlook Web App is now known as Outlook on the web, which continues to let users access their Exchange mailbox from almost any web browser.
NOTE: Supported Web browsers for Outlook on the web in Exchange 2019 are Microsoft Edge, Internet Explorer 11, and the most recent versions of Mozilla Firefox, Google Chrome, and Apple Safari.
The former Outlook Web App user interface has been updated and optimized for tablets and smart phones, in addition to desktop and laptop computers. New Exchange 2019 features include:
Exchange 2019, along with SharePoint Server 2019 and SharePoint Online, enables Outlook on the web users to link to and share documents that are stored in OneDrive for Business in an on-premises SharePoint server instead of attaching files to messages. Users in an on-premises environment can collaborate on files in the same manner that’s used in Office 365.
When an Exchange 2019 user receives a Word, Excel, or PowerPoint file in an email attachment, and the file is stored in OneDrive for Business or on-premises SharePoint, the user will now have the option of viewing and editing that file in Outlook on the web alongside the message. To do this, you’ll need a separate computer in your on-premises organization that’s running Office Online Server.
Exchange 2019 also brings the following improvements to document collaboration:
The Hybrid Configuration Wizard (HCW) that was included with Exchange 2013 is moving to become a cloud-based application. When you choose to configure a hybrid deployment in Exchange 2019, you’ll be prompted to download and install the wizard as a small app. The wizard will function the same in previous versions of Exchange, with a few new benefits:
In addition to Hybrid Configuration Wizard improvements, multi-forest hybrid deployments are being simplified with Azure Active Directory Connect (AADConnect). AADConnect introduces management agents that will make it significantly easier to synchronize multiple on-premises Active Directory forests with a single Office 365 tenant.
Exchange ActiveSync clients will be seamlessly redirected to Office 365 when a user’s mailbox is moved to Exchange Online. To support this, ActiveSync clients need to support HTTP 451 redirect. When a client is redirected, the profile on the device is updated with the URL of the Exchange Online service. This means the client will no longer attempt to contact the on-premises Exchange server when trying to find the mailbox.
To comply with business standards and industry regulations, organizations need to protect sensitive information and prevent its inadvertent disclosure. Examples of sensitive information that you might want to prevent from leaking outside your organization include credit card numbers, social security numbers, health records, or other personally identifiable information (PII). With a DLP policy and mail flow rules (also known as transport rules) in Exchange 2019, you can now identify, monitor, and protect 80 different types of sensitive information with new conditions and actions:
Exchange 2019 includes the following improvements to In-Place Archiving, retention, and eDiscovery to help your organization meet its compliance needs:
In Exchange 2019, the search architecture has been redesigned. It is now based on the same engine as the modern search engines are and is directly on the mailbox in Exchange 2019. There is no content index database attached to the mailbox database as in previous versions of Exchange Server. Previously, search was a synchronous operation that was not very fault-tolerant. The new architecture is asynchronous and decentralized. It distributes the work across multiple servers and keeps retrying if any servers are too busy. This means that we can return results more reliability, and faster.
Another advantage of the new architecture is that search scalability is improved. The number of mailboxes you can search at once using the console has increased from 5k to 10k for both mailboxes and archive mailboxes, allowing you to search a total of 20k mailboxes at the same time.
REFERENCES:
What is new in Exchange Server
What is discontinued in Exchange Server
Exchange Server TLS Guidance
Exchange Architecture
For most companies today, we want to make access to OWA easy for the users. Most folks will just type in mail.domain.com/owa or something of the like to get to the OWA page. If you don’t use HTTPS by default though, you will not be able to access OWA and will get an error on the page. We need to be able to redirect the HTTP query to go to SSL or HTTPS so that you get the proper logon page and have the access secured by SSL PKI as per the security standard.
Now, most bigger companies will install a load balancer that will program the redirection to HTTPS when the request is made before it hits the Exchange Server. But, for small companies, like mine, that cannot afford a load balancer, we need a native way in Windows and Exchange to be able to perform the same task and have it redirect to HTTPS so that your users are not confused when typing in the address.
The following shows how to configure IIS so that it natively redirects all HTTP requests for OWA to HTTPS.
By default in Exchange Server, the URL https://<ServerName> redirects users to https://<ServerName>/owa. But, if anyone tries to access Outlook on the web (formerly known as Outlook Web App) by using http://<ServerName> or http://<ServerName>/owa, they’ll get an error.
You can configure http redirection for Outlook on the web so that requests for http://<ServerName> or http://<ServerName>/owa are automatically redirected to https://<ServerName>/owa. This requires the following configuration steps in Internet Information Services (IIS):
Note: To perform this procedure on the command line, open an elevated command prompt on the Exchange server (a Command Prompt window you open by selecting Run as administrator) and run the following command:
1 | %windir%\system32\inetsrv\appcmd.exe set config "Default Web Site" -section:access -sslFlags:None -commit:APPHOST |
When you change the Require SSL setting on a website in IIS, the setting is automatically inherited by all virtual directories in the website. Because we’re only interested in configuring Outlook on the web, you need to restore the Require SSL setting for other virtual directories that had it enabled by default.
Based on the information in the Default Require SSL and HTTP Redirect settings in the default website on an Exchange server section, use the following procedure to restore the setting on the other virtual directories where Require SSL was enabled by default:
NOTE: PLEASE REMEMBER TO NOT CHECK THE “Require SSL” FOR THE /OWA DIRECTORY. THIS WILL CAUSE A 403 Access Denied ERROR WHEN TRYING TO REDIRECT.
Note: To perform these procedures on the command line, replace <VirtualDirectory> with the name of the virtual directory, and run the following command in an elevated command prompt:
1 | %windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/<VirtualDirectory>" -section:Access -sslFlags:Ssl,Ssl128 -commit:APPHOST |
Note: To perform this procedure on the command line, open an elevated command prompt and run the following command:
1 | %windir%\system32\inetsrv\appcmd.exe set config "Default Web Site" -section:httpredirect -enabled:true -destination:"/owa" -childOnly:true |
When you enable redirection on a website in IIS, the setting is automatically inherited by all virtual directories in the website. Because we’re only interested in configuring redirection for the default website, you need to remove the redirect setting from all virtual directories. By default, no directories or virtual directories in the default website are enabled for redirection. For more information, see the Default Require SSL and HTTP Redirect settings in the default website on an Exchange server section.
Use the following procedure to remove the redirect setting from all virtual directories in the default website (including /owa):
Note: To perform these procedures on the command line, replace <VirtualDirectory> with the name of the virtual directory, and run the following command in an elevated command prompt:
1 | %windir%\system32\inetsrv\appcmd.exe set config "Default Web Site/<VirtualDirectory>" -section:httpredirect -enabled:false -destination:"" -childOnly:false |
Note: You can also perform an IISRESET from and Elevated PowerShell Prompt.
My biggest take away from this was NOT setting the SSL Requirement Properly in the /owa directory when configuring this. By default, the setting is to Require SSL, but to redirect properly, you have to have that Virtual Directory in IIS set to NOT Require SSL. Having the 403 error was driving me crazy. I had to get someone else to look at it, but they didn’t catch it either! That is why I made a point to write this article with the /owa catch in mind. I hope this helps!
REFERENCES:
Configure http to https redirection for Outlook on the web in Exchange Server
Default Require SSL and HTTP Redirect settings in the default website on an Exchange server
I wanted to pass this announcement along to everyone so that they are aware of the support ending for Exchange 2010. I personally have noticed a large number of Exchange 2010 environments starting to show age as the newer Outlook clients are having performance issues with Exchange 2010. If your team has not planned an upgrade to Exchange 2016 (you cannot upgrade directly from Exchange 2010 to 2019), I would advise that your team do so very soon. Exchange 2010 has been a great product for many years, but it is finally time for it to retire and allow the next generation of Messaging Services take the stage.
Announced today, and in alignment with Office 2010 and SharePoint 2010, and after investigating and analyzing the deployment state of an extensive number of Exchange customers, Microsoft has decided to move Extended Support date for Exchange Server 2010 from January 14th 2020 to October 13th 2020.
After October 13th 2020, Microsoft will no longer provide technical support for problems that may occur with Exchange 2010 including:
– bug fixes for issues that are discovered and that may impact the stability and usability of the server
– security fixes for vulnerabilities that are discovered and that may make the server vulnerable to security breaches
– and time zone updates
Customer installations of Exchange 2010 will, of course, continue to run after this date; however, due to the changes and potential end of support risks, Microsoft strongly recommends customers migrate from Exchange 2010 as soon as possible.
In my career, I have to be able to be efficient as most of my projects are on a time crunch schedule. Being able to quickly configure Exchange when setting up a server environment is crucial to the success of the project.
While still honing my skills in PowerShell, I was attempting to create my own script to help configure all of the Virtual Directories in one shot rather than go to each setting and configure them manually. It did not go very well, so as I do, I research and find great professionals that do great work in scripting so that I may learn from them.
In doing so, I found Paul Cunningham’s script that performs this. I took the following script and modified it to add the PowerShell Virtual Directory to it as I like to configure that as well.
***YOU CAN REM THE LINES OUT SHOULD YOU NOT WANT TO CONFIGURE THAT DIRECTORY***
Here is my version of the script:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 | <# .SYNOPSIS ConfigureExchangeURLs.ps1 .DESCRIPTION PowerShell script to configure the Client Access server URLs for Microsoft Exchange Server 2013/2016. All Client Access server URLs will be set to the same namespace. If you are using separate namespaces for each CAS service this script will not handle that. The script sets Outlook Anywhere to use NTLM with SSL required by default. If you have different auth requirements for Outlook Anywhere use the optional parameters to set those. .PARAMETER Server The name(s) of the server(s) you are configuring. .PARAMETER InternalURL The internal namespace you are using. .PARAMETER ExternalURL The external namespace you are using. .PARAMETER InternalSSL Specifies the internal SSL requirement for Outlook Anywhere. Defaults to True (SSL required). .PARAMETER ExternalSSL Specifies the external SSL requirement for Outlook Anywhere. Defaults to True (SSL required). .EXAMPLE .\ConfigureExchangeURLs.ps1 -Server sydex1 -InternalURL mail.exchangeserverpro.net -ExternalURL mail.exchangeserverpro.net .EXAMPLE .\ConfigureExchangeURLs.ps1 -Server sydex1,sydex2 -InternalURL mail.exchangeserverpro.net -ExternalURL mail.exchangeserverpro.net .LINK http://exchangeserverpro.com/powershell-script-configure-exchange-urls/ .NOTES Written by: Paul Cunningham For more Exchange Server tips, tricks and news check out Exchange Server Pro. * Website: http://exchangeserverpro.com * Twitter: http://twitter.com/exchservpro Find me on: * My Blog: http://paulcunningham.me * Twitter: https://twitter.com/paulcunningham * LinkedIn: http://au.linkedin.com/in/cunninghamp/ * Github: https://github.com/cunninghamp License: The MIT License (MIT) Copyright (c) 2015 Paul Cunningham Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Change Log: V1.00, 13/11/2014 - Initial version V1.01, 26/06/2015 - Added MAPI/HTTP URL configuration V1.02, 27/08/2015 - Improved error handling, can now specify multiple servers to configure at once. V1.03, 09/09/2015 - ExternalURL can now be $null V1.04, 17/11/2016 - Removed Outlook Anywhere auth settings, script now sets URLs only V1.05, 18/11/2016 - Added AutodiscoverSCP option so it can be set to a different URL than other services V1.06, 25/06/2019 - Added PowerShell Virtual Directory Configuration Requiring SSL and using Basic Authentication .ADDENDUM V1.06 Modified by Lance Lingerfelt for similar use. * Website: http://www.ldlnet.net * IT Blog: http://itblog.ldlnet.net #> #requires -version 2 [CmdletBinding()] param( [Parameter( Position=0,Mandatory=$true)] [string[]]$Server, [Parameter( Mandatory=$true)] [string]$InternalURL, [Parameter( Mandatory=$true)] [AllowEmptyString()] [string]$ExternalURL, [Parameter( Mandatory=$false)] [string]$AutodiscoverSCP, [Parameter( Mandatory=$false)] [Boolean]$InternalSSL=$true, [Parameter( Mandatory=$false)] [Boolean]$ExternalSSL=$true ) #................................... # Script #................................... Begin { #Add Exchange snapin if not already loaded in the PowerShell session if (Test-Path $env:ExchangeInstallPath\bin\RemoteExchange.ps1) { . $env:ExchangeInstallPath\bin\RemoteExchange.ps1 Connect-ExchangeServer -auto -AllowClobber } else { Write-Warning "Exchange Server management tools are not installed on this computer." EXIT } } Process { foreach ($i in $server) { if ((Get-ExchangeServer $i -ErrorAction SilentlyContinue).IsClientAccessServer) { Write-Host "----------------------------------------" Write-Host " Configuring $i" Write-Host "----------------------------------------`r`n" Write-Host "Values:" Write-Host " - Internal URL: $InternalURL" Write-Host " - External URL: $ExternalURL" Write-Host " - Outlook Anywhere internal SSL required: $InternalSSL" Write-Host " - Outlook Anywhere external SSL required: $ExternalSSL" Write-Host "`r`n" Write-Host "Configuring Outlook Anywhere URLs" $OutlookAnywhere = Get-OutlookAnywhere -Server $i $OutlookAnywhere | Set-OutlookAnywhere -ExternalHostname $externalurl -InternalHostname $internalurl ` -ExternalClientsRequireSsl $ExternalSSL -InternalClientsRequireSsl $InternalSSL ` -ExternalClientAuthenticationMethod $OutlookAnywhere.ExternalClientAuthenticationMethod if ($externalurl -eq "") { Write-Host "Configuring Outlook Web App URLs" Get-OwaVirtualDirectory -Server $i | Set-OwaVirtualDirectory -ExternalUrl $null -InternalUrl https://$internalurl/owa Write-Host "Configuring Exchange Control Panel URLs" Get-EcpVirtualDirectory -Server $i | Set-EcpVirtualDirectory -ExternalUrl $null -InternalUrl https://$internalurl/ecp Write-Host "Configuring ActiveSync URLs" Get-ActiveSyncVirtualDirectory -Server $i | Set-ActiveSyncVirtualDirectory -ExternalUrl $null -InternalUrl https://$internalurl/Microsoft-Server-ActiveSync Write-Host "Configuring Exchange Web Services URLs" Get-WebServicesVirtualDirectory -Server $i | Set-WebServicesVirtualDirectory -ExternalUrl $null -InternalUrl https://$internalurl/EWS/Exchange.asmx Write-Host "Configuring Offline Address Book URLs" Get-OabVirtualDirectory -Server $i | Set-OabVirtualDirectory -ExternalUrl $null -InternalUrl https://$internalurl/OAB Write-Host "Configuring MAPI/HTTP URLs" Get-MapiVirtualDirectory -Server $i | Set-MapiVirtualDirectory -ExternalUrl $null -InternalUrl https://$internalurl/mapi Write-Host "Configuring PowerShell URLs" Get-PowerShellVirtualDirectory -Server $i | Set-PowerShellVirtualDirectory -ExternalUrl $null -InternalUrl https://$internalurl/PowerShell -BasicAuthentication $True -RequireSSL $True -Confirm:$False } else { Write-Host "Configuring Outlook Web App URLs" Get-OwaVirtualDirectory -Server $i | Set-OwaVirtualDirectory -ExternalUrl https://$externalurl/owa -InternalUrl https://$internalurl/owa Write-Host "Configuring Exchange Control Panel URLs" Get-EcpVirtualDirectory -Server $i | Set-EcpVirtualDirectory -ExternalUrl https://$externalurl/ecp -InternalUrl https://$internalurl/ecp Write-Host "Configuring ActiveSync URLs" Get-ActiveSyncVirtualDirectory -Server $i | Set-ActiveSyncVirtualDirectory -ExternalUrl https://$externalurl/Microsoft-Server-ActiveSync -InternalUrl https://$internalurl/Microsoft-Server-ActiveSync Write-Host "Configuring Exchange Web Services URLs" Get-WebServicesVirtualDirectory -Server $i | Set-WebServicesVirtualDirectory -ExternalUrl https://$externalurl/EWS/Exchange.asmx -InternalUrl https://$internalurl/EWS/Exchange.asmx Write-Host "Configuring Offline Address Book URLs" Get-OabVirtualDirectory -Server $i | Set-OabVirtualDirectory -ExternalUrl https://$externalurl/OAB -InternalUrl https://$internalurl/OAB Write-Host "Configuring MAPI/HTTP URLs" Get-MapiVirtualDirectory -Server $i | Set-MapiVirtualDirectory -ExternalUrl https://$externalurl/mapi -InternalUrl https://$internalurl/mapi Write-Host "Configuring PowerShell URLs" Get-PowerShellVirtualDirectory -Server $i | Set-PowerShellVirtualDirectory -ExternalUrl https://$externalurl/PowerShell -InternalUrl https://$internalurl/PowerShell -BasicAuthentication $True -RequireSSL $True -Confirm:$False } Write-Host "Configuring Autodiscover" if ($AutodiscoverSCP) { Get-ClientAccessServer $i | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://$AutodiscoverSCP/Autodiscover/Autodiscover.xml } else { Get-ClientAccessServer $i | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://$internalurl/Autodiscover/Autodiscover.xml } Write-Host "`r`n" } else { Write-Host -ForegroundColor Yellow "$i is not a Client Access server." } } } End { Write-Host "Finished processing all servers specified. Consider running Get-CASHealthCheck.ps1 to test your Client Access namespace and SSL configuration." -ForegroundColor Yellow Write-Host "Refer to http://exchangeserverpro.com/testing-exchange-server-2013-client-access-server-health-with-powershell/ for more details." Write-Host "Also check out http://itblog.ldlnet.net for Lance's IT Blog of information!" -ForegroundColor Gray } #................................... # Finished #................................... |
1 | .\ConfigureExchangeURLs.ps1 -Server EX01 -InternalURL mail.ldlnet.net -ExternalURL mail.ldlnet.net |
1 | .\ConfigureExchangeURLs.ps1 -Server EX01,EX02,EX03 -InternalURL mail.ldlnet.net -ExternalURL mail.ldlnet.net |
REFERENCES:
Exchange Server Client Access URL Configuration Script
PowerShell Script to Configure Exchange Server Client Access URLs
