Send Connector: If you prefer to do things in the GUI, then Mail flow > Send Connectors > Select the send connector > Edit > Maximum Send Message (MB) > Set accordingly > Save.
Receive Connector: Mail Flow > Receive Connectors > Select the receive connector (usually the Default Frontend {server-name} connector > Edit > Maximum Receive Message Size > Save.
User ‘Mailbox’: Exchange Size Limits (PowerShell)
You can set individual limits on a particular mailbox. BUT Remember MOST RESTRICTIVE LIMITS WILL APPLY, so if you set a mailbox to 50o0Mb send receive, then, if the connectors the mail travels through, have a more restrictive figure, or the global transport figure is more restrictive the message WILL BE BLOCKED. UNLESS: The message is between two mailboxes internally. So it’s sensible practice to only set a mailbox restriction to LOWER than the connectors or system wide settings.
User ‘Mailbox’: Exchange Size Limits (Exchange Admin Center)
Again this can also be done front the web management console > Recipients > Mailboxes > Select the user to be changed > Edit > Mailbox Features > Message Size Restrictions > View Details > Set accordingly > OK > Save.
I’ve Done All This And It Still Wont Work?
Sometimes the settings above don’t take effect until all the AppPools in IIS (on the CAS servers) have been restarted, an IISRESET command should solve the problem, (or a reboot if you can handle the downtime.) However even then in some cases you will continue to see the same error message. There are three places that it can still be misconfigured.
OWA Config File
Open the File located at;
%ExchangeInstallPath%ClientAccess\owa\web.config
Locate and set the maxRequestLength (NOTE: the value is in Kilobits)
If you attempt to edit the authOrig attribute of a mail enabled group using ADSIedit you will get the following error.
There is no editor registered to handle this attribute type.
Why would you be doing this? This is done when you want to restrict who can email a group.
Solution
If you are running either on-premises Microsoft Exchange (or are running in Hybrid Exchange mode, and have retained an Exchange server for management,) You can simply use the Exchange Admin Center to add the person or group that you want to restrict access to.
Recipients > Groups > Group-Name > Edit > Delivery Management > Set accordingly.
Note: As I’m in Hybrid mode, and have AAD Sync setup, if I attempt to look at this group in O365 / Exchange online, it simply says.
You can only manage this group in your on premises environment. Use Active Directory users and groups, or Exchange AdminCenter tools to edit or delete this group.
Technical Pedantry: The fact it’s been called ‘Active Directory Users and Computers‘ since Windows 2000 makes my OCD flinch at that comment.
Use PowerShell
You can (if you have no access to Exchange Management tools) simply use PowerShell, the syntax is as follows.
[box]
Set-ADGroup -Identity "The-Group" -Server The-Domain-Controller -Add @{authOrig=@('The User or Group to Grand access to')}
e.g.
Set-ADGroup -Identity "CN=DG-Test-Disty-Group,CN=Users,DC=pnl,DC=com" -Server PNL-MGMT.pnl.com -Add @{authOrig=@('CN=Pete Long,CN=Users,DC=pnl,DC=com')}
[/box]
Then to prove it’s not all ‘smoke and mirrors’ you can go back to ADSIedit and check.
Related Articles, References, Credits, or External Links
This has plagued me for a while – but as the server was my test server it’s had to wait. When attempting to open the Exchange Admin Center website I got the following;
Server Error in ‘/ecp’ Application
Object reference not set to an instance of an object.
Object Reference Not Set: Solution
First stop was to make sure all the Exchange services were running.
[box]
Get-Service *Exchange* | Start-Service
[/box]
Then a search told me to check that the bindings for the front and back end Exchange websites, (they were correct.)
Correct Exchange Certificate Bindings (Object Reference Not Set)
Default Web Site (Front End): This should be ‘bound’ to your publicly signed certificate like so.
Exchange Back End: This should be ‘bound’ to your a locally signed certificate called Microsoft Exchange certificate like so.
Note: If there’s a problem with that cert, you can generate a new one with a New-ExchangeCertificate command.
Sadly all these did not fix my error, but the error is probably related to certificates, I then came across this article. and it suggested I run the following command, and to make sure it did not error (however as you can see it did error).
At this point I made a mistake – I tried to replace the OAuth cert with my normal publicly signed (Let’s Encrypt) certificate and this happened.
The certificate with thumbprint “XXXXXXXXXXXXXXXXXXXXXXXXXXX” has a private key that is not exportable. + CategoryInfo : InvalidArgument: (:) [Set-AuthConfig], TaskException + FullyQualifiedErrorId : [Server=PNL-MAIL-2019,RequestId=620c92eb-d67d-4b5d-9bc5-63262530b500,TimeStamp=19/09/202 3 07:40:10] [FailureCategory=Cmdlet-TaskException] 9D5A2595,Microsoft.Exchange.Management.SystemConfigurationTasks .SetAuthConfig + PSComputerName : pnl-mail-2019.pnl.com
With the benefit of hidsight,I was probably going in the wrong direction, but what it did do, was make me jump on the internet, buy a new publically signed SSL certificate for SIX DOLLARS, import that, fix the bindings, and, (because I’m in Hybrid mode.) Change the connector certificates to the new one.
And – everything worked again!
Related Articles, References, Credits, or External Links
If you attempt to connect to and send mail via command line to your Exchange Server, you may see the following error after you end the data section of the operation.
451 4.7.0 Temporary server error. Please try again later. PRX5
Solution 451 4.7.1 Error
Log into Exchange Amin Center > Mail Flow > Receive Connectors > Default Frontend {Server-Name} > Edit > Scope > Select the IPV4 entry (Either Remove it and ad a new one or edit it)
Specify the IP address you want to use.
So, it should look like this > Save > Exit Exchange Management.
Open Notepad (Note: you need to run as administrator). Navigate to C:\Windows 32\Drivers\Etc locate the hosts file (If you can’t see it change the option to “All Files“
At the bottom of the file enter the IP hostname and FQDN of the server then save and exit.
Then restart the Exchange Transport Service.
Related Articles, References, Credits, or External Links
If you have a vanilla install of Exchange, it will clean up the UnifiedContent folder on a four hourly schedule. the problem occurs if you have moved your Exchanges ‘Queue” directory. This will also relocate the UnifiedContent folder, but then Exchange, will still try (and fail) to tidy it up in the original location, (because it’s not there anymore!)
Typically, you will see your UnifiedContent folder growing slowly like so.
Note: You can tell by the folder path (above), that the queue directory is ‘non-standard’ i.e. I’ve placed the mail queue on its own partition, (Drive letter Q:). COPY THE PATH TO UNIFIEDCONTENT FOLDER TO THE CLIPBOARD.
Solution: UnifiedContent Growing
Locate your Antimalware.xml file, as you can see in my example (below) This lives in the Bin subfolder in the Exchange deployment folder, like the quote folder, mines in a non-standard folder also (I like to be different). If you have a standard deployment the file is usually located in.
Search withing the file for the following text string.
[box]
TransportRoles\data\Temp\UnifiedContent
[/box]
You will see that this is the location that the Microsoft Exchange Health Monitor Service expects the UnifiedContent folder to be at, and yours will probably be pointing to,
Change the ENTIRE path (from the semi-colon to the quotes) and replace it with the ACTUAL path to your UnifiedContent folder, (you copied earlier). Then save the file and exit Notepad.
Before the change will take place, you need to restart the Microsoft Exchange Health Manager service.
[box]
Restart-Service MSExchangeHM
[/box]
Now nothing will happen for four hours (you can manually delete some of the older files if you are having capacity issues!) After four hours all the older files should have been purged, and this process will continue to prevent the problem from re-occurring again.
Related Articles, References, Credits, or External Links
While attempting to PowerShell to Exchange Online today, I tried to do this by using my usual method, and repeatedly got this error.
[box]
New-PSSession : [outlook.office365.com] Connecting to remote server outlook.office365.com failed with the following
error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:12
+ $Session = New-PSSession -ConfigurationName Microsoft.Exchange -Conne ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
gTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed
[/box]
I double checked the username/password was correct, and that the user was a global admin.
PowerShell to Exchange Online: Solution
After some searching it would seem that if the user is using MFA or you need to connect via modern authentication this can happen! Open an administrative PowerShell window, and execute the following commands;
[box]
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Then Press A {Enter}
Install-Module -Name PowerShellGet -Force
If Prompted Press Y and {Enter}
Install-Module -Name ExchangeOnlineManagement -Force
Connect-ExchangeOnline -UserPrincipalName username@domain.com -ShowProgress $true
Log on interactively
[/box]
Then continue as normal.
Related Articles, References, Credits, or External Links
If you have a mailbox move that’s showing as StalledDueToTarget_Processor, that’s quite common (I see that a lot).
Solution: StalledDueToTarget_Processor
Firstly how long have you waited? I see this when I’m moving a LOT of mailboxes, and most of the time this problem resolves itself – if you are patient enough, (and your users will be unaffected while this is going on).
If you have waited and there’s still no movement, you can try the following, locate the MSExchangeMailboxReplicaiton.exe.config file (it will be in your exchange/bin folder).
Edit the file, locate ‘MaxMRSConnections’ value and change it to 20, then save the file.
Note: I change these values on the source and destination Exchange servers, But documentation says you only need to do it on the sourse server.
Then restart the Microsodt Exchange Replication service on BOTH Exchange servers
Update Feb 2023: I was moving about 1000 mialboxes, and roughly a third were stuck in StalledDueToTarget_Processor. So ‘after working hours‘ I rebooted both Exchange servers, and the status changed to failed. I cancelled the move requests, and restarted the migration, this time thay all completed sucessfully.(PL)
Related Articles, References, Credits, or External Links
If Exchange 2016 was Exchange 2013 in a pretty dress, then with Exchange 2019 it’s simply added a hat. In the past, every third Exchange release was a major rebuild, but Exchange 2016 is simply Exchange version 15.1 (Exchange 2013 was 15.0 and Exchange 2016 is version 15.1).
So the Exchange 2019 Migration is pretty much the same as it was from 2013 > 2016, or even 2016 > 2016.
There should be NO Exchange 2010 servers in existence before deploying Exchange 2019. You would need to upgrade to 2013 (CU21 minimum)/2016 (CU 11 minimum) first.
There’s no Unified Comms Role with Exchange any more! If you need to upgrade look at Microsoft Teams.
Forest Functional Levels should be, (at least) Server 2012 R2.
WARNING: Memory recommendations are 128GB (Mailbox server) and 64GB (Edge Transport server). Make sure you have enough compute!
Edge Server Role is still supported.
Windows Server Core (2019/2022) is supported with Exchange 2019.
Windows Server Nano is NOT supported.
Windows Server 2019 (Standard or Datacenter) and Windows Server 2022 (Standard or Datacenter) Note: Exchange 2019 CU 12 minimum, are supported host Operating systems.
Outlook 2013 (and newer), and Outlook for mac 2016 (and newer) is supported.
Solution
As with all Exchange migrations make sure your Active Directory Domain/DNS/Existing Exchange organisation is healthy before you start. Then upgrade the existing Exchange to the latest cumulative update.
Exchange 2019 Prerequisites
You will need your Server 2012R2 or Server 2016 server fully updated and added to your domain, then to add the required roles and services use the following Powershell commands for Server 2012, 2016 and 2019;
Now Required on Server 2012 R2, 2016, and 2019: You will need to install .Net 4.8 (link).
Server 2022: .Net 4.8 is already included in Server 2022!
You need to install the MS Unified Communications API 4.0 (link).
You will also need to install Microsoft Visual C++ (link)
You will also now have to install the ‘IIS Rewrite Module’ (link)
Either download the Exchange 2019 install media, or insert the Exchange 2019 DVD, and launch setup.exe > Next > Next > Files will be copied over.
Don’t I need to extend the schema, forest or domain? The setup does all this for you, you don’t need to do this manually anymore, (yes you can manually do this before installing, if you want to, but unless your schema master is in a different root domain, or you’re not a schema admin, then I don’t see the point!)
Introduction Page > Next > At the EULA tick “I Accept…” > Next > Tick “Use Recommended settings” > Next.
Select ‘Mailbox role’, and ‘Automatically install Windows Server roles and features…” > Next > Select the install directory, Note: In production you probably DON’T want this on the Windows System drive > Next > Unless you have a reason to disable Malware scanning then select ‘No’ > Next.
Readiness Checks > Fix and Errors and heed any warnings > Install > The product will install, this will take a long time!
Finish > Reboot the server.
An there’s our new Exchange 2019 Server.
Exchange 2019 EnterProduct Key
Servers > Servers > Select the 2019 Exchange Server > Enter Product Key > Save
Note: On the pre-release version of Exchange 2019, the Exchange 2016 keys worked fine.
At the warning click OK.
Note: You can also enter the product key using the Command Shell, if you prefer.
As directed Restart the ‘Microsoft Exchange Information Store’ service.
[box]Restart-Service MSExchangeIS[/box]
Transfer Exchange Certificate to Exchange 2019
Note: The ability to Export, Import & Renew certificates and creation/completion of certificate requests has been removed from the Exchange Admin Center. These changes will affect all cumulative update (CU) releases of Microsoft Exchange Server 2019 (CU12 and later) and Microsoft Exchange Server 2016 (CU23 and later).
I will leave the older (GUI) method, below for completeness – but all modern Exchange builds will need you to Open the Exchange Management Shell and perform the certificate migration via PowerShell
Transfer Certificates (PowerShell)
On your C: drive create a new folder called CERT > Open an Administrative Exchange Managment Shell window on the SOURCE Exchange server.
[box]
Get-ExchangeCertificate -Server {Server-Name}
[/box]
Identify the certificate you require (by Subject) > Copy the Thumbprint text > Replace the thumbprint in this text with your thumbprint, then execute the following two commands.
Transfer Certificates (ExchangeAdmin Centre {Older build versions only})
I’m using a wildcard certificate so I want to export the cert form my Exchange 2016 server and import it onto my new Exchange 2019 Server. You will want to do the same if you have a certificate with your public domain name on it and this will be your ‘internet facing’ Exchange server. Servers > Certificates > Select the Exchange 2016 Server, in the drop down menu > Select The Certificate > Click the ellipses (three dots) > Export Exchange Certificate > Supply a UNC path and password > OK.
Change the Dropdown to the Exchange 2019 Server > Click the ellipsis > Import Exchange Certificate > Supply the UNC path and password you used (above) > Next.
Add in the Exchange 2019 Server > Finish.
Exchange 2019 Assign Services to Certificate
Select the newly imported certificate> Edit > Services > Select the services > Save > Note: Here I’m selecting SMTP and IIS. (You cant use a wildcard cert for IMAP,POP).
Exchange 2019 Changing the Exchange Web Services URLs
Exchange relies heavily on web based services, and it needs the URLs setting accordingly. (remeber for Outlook Anywhere/OWA ets you might need to change firewall settings or repoint load balancers WAP server etc to the NEW 2019 server (and let it proxy these connections to the olde rExchange servers, while they still exist).
Servers > Databases > Exchange always gives databases annoying names > Select the Database on the 2019 Exchange Server > Edit > Rename it > Save.
Note: The path to the Database retains the original name (we will fix that in the next step).
Exchange 2019 Migration Move Mailbox Database
I’m pretty old school, I like my Exchange databases on their own drive/partition, and I like the logs on another drive/partition. To move both the Database and the Logs;
Mail Flow > Send Connectors > Select your mail SMTP connector(s) > Edit > Scoping > Source Server section > Add > Add in the new server > OK > Save.
Note: The Exchange server will now need to have TCP port 25 (SMTP) open outbound on your corporate firewall.
Hybrid (On-Prem) Exchange Migration Note
If your on-premise Exchange is part of an Office 365 Hybrid deployment you will need to add the new server to the ‘scope’ for that connector also!
Decommission Exchange 2016
From this point forward we are going to start getting rid of our Exchange 2016 server, they can of course coexist, (if you wanted to wait a while).
For that reason I change the ‘mail flow’ on the firewall to point to the new Exchange server at this point, and the HTTP access for OWA, Outlook Anywhere, and Phone/Tablet access
Exchange 2019 Mailbox Migration
Yes you can do this in the EAC, but I prefer to do this in PowerShell. But If I don’t put this here, I’ll get emails! Recipients > Migration > Add > Move to a different Database > Add in the mailboxes/users > Next.
Give the ‘Batch’ a name > Select to move Archive mailboxes (if you have them) > Select the destination (Exchange 2019) Database > Again if using archive mailboxes, select the target archive mailbox database > Set the bad Item limit to 99 > Next > Select Automatically Start > Select Automatically Finish > New.
From this point, this is where I don’t like the EAC it takes AGES to update with progress! From the Exchange Shell you can get an up to date view of that is going on!
For a better list of commands for moving user mailboxes, and monitoring the migration, and removing the move requests when you are finished, see the following article;
In addition to the user mailboxes there are a multitude of different ‘System mailboxes’ that might be hanging around, before we can get rid of the Exchange 2016 Database we need to migrate those.
1. Log onto the Exchange Server.
2. Start > All Programs > Exchange Management Console > Organisation Configuration > Mailbox > Offline address Book > Create a new one (Must have a different name to {Default}.
3. Delete the Old Offline Address Book.
4. Set the one you created as the default.
WAIT 20 MINUTES – If the Problem Persists
1. Log onto the Exchange Server.
2. Start > All Programs > Exchange Management Console > Server Configuration > Mailbox.
3. Select the Mailbox store in the middle section > Right Click > Properties.
4. Client Settings tab > Browse > Select the Address book you created above > OK > OK.
WAIT 20 MINUTES
Note: I’ve also fixed by creating a new mail profile – though when I switched back to the original one it was ok – so I may not have been patient enough.
Related Articles, References, Credits, or External Links
Exchange has been this way for a long time here’s me explaining this very problem with older versions of Exchange. If you create a ‘Group’, be that a Distribution Group, or a ‘Microsoft 365’ Group, the default setting is to NOT ALLOW mail from anyone outside your organisation. If you attempt to send mail to that group you will see errors like these;
Errors;
550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender was not authenticated when sending to this group
550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender not authenticated when sending to the group’
550 5.7.193 UnifiedGroupAgent; Delivery failed because the sender isn’t a group member or external senders aren’t permitted to send to this group.
Allow External Senders (On Premises & Hybrid Exchange)
If you have your own on premises Exchange server, this includes those of you that have migrated to Exchange online, but are in Hybrid Mode and are syncing your domain objects into Microsoft/Office 365 (Azure). Then you should change this setting in the on premises Exchange Admin Centre.
Recipients > Groups > Select the group in question > Edit > Delivery Management > Change to ‘Senders inside and outside of my organisation’ > Save.
Note: Remember in hybrid mode this will need to sync to Microsoft online, so apply the ‘cup of coffee rule’ before testing it.
Recipients > Groups > Select the group in question > Edit > Delivery Management > Change to ‘Senders inside and outside of my organisation’ > Save.
New Exchange Admin Center
Microsoft 365 Groups: Recipients > Groups > Microsoft 365 > ‘Double Click’ the group in question > Settings > Allow external senders to email this group > Save.
Distribution Groups: Recipients > Groups > Distribution List > ‘Double Click’ the group in question > Settings > Edit Delivery Management.
Allow messages from people inside and outside my organisation > Save changes.
Related Articles, References, Credits, or External Links
