Some Notes on the Machines

This is is caused by bad permissions in a receive connector. The fix:

1. Open ADSIEdit
2. Browse to Configuration, Services, Microsoft Exchange, , Administrative Groups, Exchange Administrative Group, Servers, , Protocols, SMTP Receive Connectors
3. Open the properties for the receive connector(s) involved in the transmissions you are debugging
4. Open the Security Tab. Under “Authenticated Users”, make sure “Accept any Sender” and “Accept Authoritative Domain Sender” are checked.
5. Wait five or ten seconds, and try again.
6. If still not, or if it works for a little while and then does the error again, you probably have severe issues in your Exchange. For a stopgap, you can set permissions for Everyone, but an Exchange rebuild is probably warranted.

From the extraordinary Mike Hunsinger.

The method below has worked perfectly on several servers and has not caused a recovery situation. That said, assure there’s good backups and perform these procedures word-for-word as these Exchange updates have been known to bootloop and bluescreen servers, particularly SBS servers when the original (and these days, ancient) install was not very cleanly done.

The key is to determine the current Exchange SP level, then based on the current version, plan your updates like this: First, install the highest-level rollup for the current SP. Then install the next SP by version. Followed by that SP’s highest-level rollup, then the next SP.

Here’s an example:

Your 2010 Exchange Server is using SP1 RU 3 (Roll-Up3). You intend to upgrade this system to SP3 RU14 (Latest version of Exchange).

Here’s the order in which you should install the updates based on this exchanges current version:

1. Update Rollup 8 for Exchange Server 2010 SP1 (Highest version of SP1)
2. Exchange Server 2010 SP2
3. Update Rollup 8 for Exchange Server 2010 SP2 (Highest version of SP2)
4. Exchange Server 2010 SP3
5. Update Rollup 14 for Exchange Server 2010 SP3 (Highest version of SP3)

Notes found to be important:

• Assure the server’s OS itself is running the latest service pack for Windows Server.

• Exchange SP’s must be downloaded from the web and installed using an exe. Roll-Ups must only be installed via Windows Update.

• Using this pattern of installs and installing Roll-Ups using only Windows Update, will prevent having to perform the lengthy staging process where the mailbox databases are manually converted between versions using CMD.

• Completely review the prerequisites for each Rollup and SP before installing it. There are corroborative softwares such as .net and sql client or certain hotfixes that may need to be installed prior to a given service pack or roll-up.

• During the Service Pack updates, you will see a long checklist the server is moving down while performing the upgrades. If the server errors on one of the checklist items and asks if you wish to continue or roll-back. ROLL IT BACK. Resolve the issue noted and try the update again. You want all 10 lights green when it hits the bottom of the checklist. Errors here are usually the result of insufficient permissions someplace in the server. The errors are usually easy to trace down online.

• Between every update listed. Launch the ECM. Assure the mailboxes are all listed. Then run the builtin Exchange testing. If Exchange says it’s passed, move onto the next update. If Exchange fails any factors, they must be eliminated before continuing.

• Allow up to 1 hour for the server to reboot following an Exchange SP Upgrade. It’s advisable that ILO be activated prior to installing the upgrades described in this document, so you can keep an eye on the server while it reboots.

• I usually allow 1.5h for each service pack and it’s associated rollup.

• It never goes exactly smoothly, so there’s usually some challenges to overcome during each of the updates.

Archiving and retention deletions, are only executed once every seven days in Exchange Online, unless a manual execute is performed. This is done thusly:

1. Connect Windows PowerShell to the Office 365 account.
2. Start-ManagedFolderAssistant -Identity username

where username is appropriate for the mailbox in study.

Contributed by the excellent Matt Quick:

https://mattthequick.wordpress.com/2015/11/25/connect-to-office-365-via-powershell/

$msolcred = get-credential
connect-msolservice -credential $msolcred
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $msolcred -Authentication Basic –AllowRedirection
Import-PSSession $Session

Great input:

https://technet.microsoft.com/en-us/library/dn879075%28v=exchg.150%29.aspx

From the profound Mike Crayton. We do this:

1. Create an admin role group named “Manage Distribution Groups”, with the admin role of “Distribution Groups”, setting as members the user(s) to be given this ability
2. Give them this URL for getting to the management console:
   https://outlook.office.com/ecp/

These are not very documented, and at least at this writing, the informatives in the console were incomplete. Here’s the steps I have working at this writing, postulating the domain at hand being “emaildomain.com”:

1. First, in the O365 Exchange administrative console, go to the Protection area, and the rightmost tab is “dkim”, click on that. Then try to Enable any which are disabled. You will see an error message which says you need to create two CNAMEs. The two strings given, are the alias targets, the alias names are not given. Use these in the next step.

2. Set CNAMEs in Internet DNS. The alias names are the same every time; the targets are taken from the error message in step 1. They are not always entirely predictable, sometimes you will see “0i” buried within and there may be other variations. But the result will not be very distant from this:

selector1._domainkey.emaildomain.com
CNAME to
selector1-emaildomain-com._domainkey.emaildomain.onmicrosoft.com.
TTL 3600

selector2._domainkey.emaildomain.com
CNAME to
selector2-emaildomain-com._domainkey.emaildomain.onmicrosoft.com.
TTL 3600

3. Once your DNS changes have propagated thoroughly, go back to step #1 and try to enable DKIM again for the domain whose records you have just changed. If you have done your CNAMEs correctly, O365 will turn DKIM on. You may need to wait for DNS propagation.

It is not hard. After you have created the shared mailbox, its email address will appear in the Office 365 console. We’ll call it “abcdefg@domain.com”.

1. Connect PowerShell to Exchange Online.
2. Turn publishing on for the calendar.

Set-MailboxCalendarFolder -Identity abcdefg@domain.com:\calendar -PublishEnabled $true

3. Get the URL. The following code will request all of the calendar setup parameters, including both an HTML URL for general web browsers and an ICS URL for many applications.

Get-MailboxCalendarFolder -Identity abcdefg@domain.com:\calendar

4. If you test the HTML URL now, you will see no details. Do this to put all of the details in:

Set-MailboxCalendarFolder -Identity abcdefg@domain.com:\calendar -DetailLevel FullDetails

After migrating all email accounts from an on-premises Exchange 2008 or later server to Exchange Online, there remains the problem of what to do about new Outlook profile creation. Outlook will still look for the old server name, and especially if you want to keep the old server alive for a while, you will have significant problems getting Outlook 2013 to do anything with Exchange Online. Here is what the extraordinary Matt Quick and I did recently with beautiful results.

For the sake of this discussion, “localdomain.local” is the LAN-local AD-enabled domain, and “publicdomain.pub” is the Internet domain. The on-prem Exchange originally had local DNS name “exchange.localdomain.local” and Internet DNS name “exchange.publicdomain.pub”.

1. Migrated all mailboxes from on-premises Exchange 2010 to Exchange Online. Dirsync was used for initial account setup, then turned off for the actual copyover process which was done with MessageOps.
2. In Exchange Management Shell, ran Get-ClientAccessServer to get the canonical name of on-prem Exchange (we’ll say it was EXCHANGENAME), and then Set-ClientAccessServer -Identity EXCHANGENAME -AutoDiscoverServiceInternalUri $NULL (replacing EXCHANGENAME with the actual name) to nullify as many defaults as possible.
3. Set autodiscover.localdomain.local as a CNAME to autodiscover.outlook.com.
4. Set autodiscover.publicdomain.pub as a CNAME to autodiscover.outlook.com in Internet DNS. This LAN has a local copy of publicdomain.pub in its domain controllers, so copied this record to the local server as well.
5. Unregistered the NIC for the on-premises Exchange server in DNS. The checkboxes are in the DNS tabs of both TCP/IPv4 and TCP/IPv6, within the Advanced area of the NIC. This is done so that DNS changes which are next, will not be undone automatically.
6. Removed DNS A records exchange.localdomain.local and exchange.publicdomain.pub from local and Internet DNS respectively.
7. Added DNS CNAME records exchange.localdomain.local and exchange.publicdomain.pub, both pointing to outlook.office365.com, to local and Internet DNS as appropriate.
8. Set up oldexchange.localdomain.local and oldexchange.publicdomain.pub as A records pointing to the IP being used by the on-premises Exchange, to local and Internet DNS as appropriate, for archival uses and until we are ready to decommission the on-prem Exchange altogether.

Set of steps here, worked very well just now:

https://evotec.xyz/exchange-2013-powershell-errors-out-and-exchange-2013-ecp-doesnt-work-correctly/