Ondrej Žilinec – IT Blog

Problem

Today I wanted to have day off, but customers with Exchange environments (2013/2016 and 2019) started to have a problem with e-mails delivery. They have started to receive following error in event viewer:

This event started to show couple minutes after 1.1.2022.

Messages stucked at queue and with error “Message deferred by categorized agent”:

Solution

So Antimalware has problem with date “22010100009” and error says it’s “too long”. It looks like Microsoft programmers use to record date 32b numbers and now this value is over variable limits. I think there is will hotfix pretty soon. Until hotfix we need to solve a problem. I just disabled Antimalware engine running following powershell script:

& $env:ExchangeInstallPath\Scripts\Disable-AntimalwareScanning.ps1

and restart MSExchangeTransport service afterwards:

Restart-Service MSExchangeTransport

And that’s all folks 🙂

Problem: When I do migration from Exchange 2010 to Exchange 2016 most of the time I have problem with old style Public Folders hosted on Exchange 2010. When you migrate user from Exchange 2010 to Exchange 2016 she cannot access Public Folders hosted on Exchange 2010.

Solution: You need to setup Exchange 2016 environment to be able to proxy Public Folders hosted on Exchange 2010. You need to create proxy mailbox which Exchange 2016 will use to proxy Public folders. Here are couple steps you need to do:

• Create new mailbox:

New-Mailbox -Name PFMBX1 -Database {YOUR  EX2010 DATABASE NAME}

• I preffer to hide this mailbox from other users

Set-Mailbox -Identity PFMBX1 -HiddenFromAddressListsEnabled $true

• Set on Exchange 2016 server following proxying

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMBX1

Now when Exchange 2016 users restart their Outlook clients they will see Public folders hosted on Exchange 2010.

Have a nice day,

Problem: There is a known error in Exchange 2013/2016 when you migrate user’s mailbox. After the migration is done use cannot access her new mailbox. It is possible after some time (max 15 minutes).

Cause: This is caused by outdated data cached by Autodiscover process on Exchange server. It’s called MSExchangeAutodiscoverAppPool.

Solution: You need to set application pool responsible for creation autodiscover XML file to recycle more often. You can do Recycle manually from IIS console after migration is done:

Or you can configure automatic recycling on specific condition. I most of the time configure Recycling on every minute. When all users are migrated I disable this rule:

Have a nice day,

From some update there is no relevant information about version in Exchange 2010 SP3. Let’s try it in Powershell:

It says it’s 123.4 build which should coresponds to plaint Microsoft Exchange Server 2010 SP3 (Exchange Update Rollup numbers). This is not corrent information, because those servers have UR installed.

Using EMC I can see:

Which are also incorrect information about server versions. I suppose it’s just nicer output of Powershell cmdlet 🙂

Best way to find out it’s to use EMC console on server and use “About”:

You will get information which are correct:

It’s Update Rollup 11 for Exchange Server 2010 SP3.

It’s really bad that you cannot find Exchange version of all your Exchange servers in one place (Powershell or EMC). Let’s hope they will fix it in new Update Rollup 🙂

That’s all fokls for today.

I migrated from Exchange 2003 to Exchange 2010 and since then I was receiving following event:

 

Event says:”The Microsoft Exchange Mailbox Replication service was unable to process a request due to an unexpected error”. Which means server cannot finish some request. In order to solve a problem I was looking for some replication settings. I found none. Then I looked into domain using ADSIEdit. I looked into:

CN=MailboxExportRequests, CN=MailboxReplication, CN=TeamSK, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=domain, DC=local

and I found there some old orphan move requests:

When I used Get-MoveRequest cmdlet there was none move request displayed. So I’ve deleted those old move requests using ADSIEdit and there was no more bothering event on Exchange server.

Have a nice day,

 

Over the weekend I was setting up Exchange 2010 database copies using DAG. Those databases were huge (total of 3,5 TB). Line between primary and backup datacenter was 100Mbps. This migration ran over 24 hours for couple databases. When I checked the status I saw job was running 23 hours and 20 minutes:

When I have checked status in about hour and half I saw interesting time:

This happened on all databases which ran over 24 hours 🙂 So it looks like Microsoft engineers haven’t think about job running more than 24 hours 🙂

That’s all from weekend,

When you install Exchange in environment you want to allow users to log into mails using their e-mail address. If your domain name is different from your e-mail domain, you have to add UPN suffix first. More abour it HERE. Then you need to change User Principal Name into Primary SMTP Address. I wrote little script to do so:

Get-Mailbox |
  ForEach-Object{
   Write-Host “For: ” + $_.SamAccountName
   Write-Host ”   – change UPN from: ” + $_.UserPrincipalName + ” to: ” + $_.PrimarySmtpAddress
   Set-ADUser -Identity $_.DistinguishedName -UserPrincipalName $_.PrimarySmtpAddress
 }

Have a nice day,

At one Microsoft Exchange 2010 server I was receiving too many events number 106:

This event basically describes problem with some performance counter. I had problems with about 10 performance counters and I didn’t want to deal with them separatelly. Exchange 2010 has definition its performance counters stored in directory “C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\”. There are XML files which define performance counters. Before you can manipulate with performance counters you need to run Exchange Management Shell and run in it following command:

add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup

This Snap-in allows you to use two Cmd-lets:  Remove-PerfCounters and New-PerfCounters. So let’s do two things which help us to get rid of events 106:

Deregister all performance counters for Exchange:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf>dir *.xml | foreach { Remove-PerfCounters -DefinitionFileName $_.Name }

Register all performance counters for Exchange:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf>dir *.xml | foreach { New-PerfCounters -DefinitionFileName $_.Name }

Since I reregistrered all performance counter definitions into Exchange 2010 server I have no problem with event 106.

This was quickie for today 🙂

We had Active Directory domain called DOMAIN.LOCAL. There was Exchange 2010 installed. It was fully functional. After some time I added new sub-domain/child domain SUB.DOMAIN.LOCAL and migrated users with mailboxes from DOMAIN.LOCAL to SUB.DOMAIN.LOCAL.

Problem

When users from SUB.DOMAIN.LOCAL logged into OWA they received following view:

Error stated: Exception message: Could not find any available Domain Controller in domain DC … so problem is probably in the way Exchange locates domain controllers. When users clicked F5 or refreshed website, he could see his e-mails normally.

There was also event 2130 logged on Exchange server saying Exchange Active Directory Provider could not find an available domain controller in the domain.

Solution

When you want to install Exchange into Active Directory domain, you need to prepare forest and also domain before you install it. You use setup.com (from installation DVD of Exchange) with some switches (for example /PrepareSchema, /PrepareAD,…). So new added domain SUB.DOMAIN.LOCAL to existing AD Forest was not prepared for Exchange implementation. I ran following command setup.com /PrepareDomain:SUB.DOMAIN.LOCAL:

If you have more then one domain to prepare for Exchange, you can use command setup.com /PrepareAllDomains.

The best way to run /PrepareDomain or /PrepareAllDomains is:

• to be logged domain controller with role Schema Admin
• to be member of Enterprise Admins group
• to be member of Schema Admins group

I hope you will not make same mistake as I did 🙂

 

Couple of days I’ve got question from my friend if there is way to setup Exchange mailbox to be Read-only for other users in company. I never needed it, because when someone else needed to access other’s mailbox, I just set FullAccess rights on mailbox and everythin worked fine.

Testing scenario

Exchange 2010

Tester user called Tester with following content of mailbox:

Tester user called Tester02 wich wants to access whole mailbox of user Tester, but Read-only.

When I set Reviewer for user Tester02 on mailbox Tester under Outlook:

Problem

When I connect Tester’s mailbox into Tester02’s Outlook profile I can see following:

So I can see only Inbox. I don’t see any folder underneath it. We can check this permissions also using Powershell:

When we look on mailbox folder permissions underneath Inbox, for example “Inbox\My friends” folder, we can see following:

This means that mailbox folder permissions are not inherited. So we can set permission per folder. So let’s test to add permission to folder Inbox and subfolder “My friends”:

and now we can see also subfolders under account Tester02:

This means that using Outlook or powershell commandlet Add-MailboxFolderPermission can set permissions only on one folder and these settings are not inherited! This is really weird. I couldn’t find any setting to allow inheritance.

Another way to set permissions of mailbox folders is set permissions on whole mailbox. This can be set by users which have rights to manage exchange mailboxes. Let’s look on powershell cmd-let Add-MailboxPermission. This cmdlet allows you to set just following access rights: FullAccess, SendAs, ExternalAccount, DeleteItem, ReadPermision, ChangePermision and ChangeOwner. Neither one of these rights define Read-only access to mailbox.

Solution

So there is no easy way to share whole mailbox between users in read-only manner. Only way I can think of is to run some powershell script. For example:

Add-MailboxFolderPermission tester -User tester02 -AccessRights Reviewer

 

ForEach($folder in (Get-MailboxFolderStatistics -Identity tester) )

{

$fname = “tester:” + $folder.FolderPath.Replace(“/”,”\”);

Add-MailboxFolderPermission $fname -User tester02 -AccessRights Reviewer

}

where “tester” is account with shared mailbox and “tester02” is account which want to access shared mailbox.

After this powershell commands are done, Tester02 can see Tester’s mailbox:

 

 

But when user Tester creates new folder in his mailbox, user Tester02 will not see it unless user Tester sets permissions on new mailbox folder.

I hope guys from Microsoft will solve this issue in next release of Exchange. 🙂