Ondrej Žilinec – IT Blog

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,

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. 🙂

Today was new version of Exchange testing applications released. More about it is HERE.

Last night I removed Domain Controller Role from Exchange 2007 server and we had problem in the morning with Exchange Outlook Web Access (OWA). We couldn’t log in at all. Symptomps:

• Form based authentification was enabled, but Basic was proposed to clients instead
• When users logged in they received 440 Login Timeout error

After couple minutes of googling I found this article which solved problem.

IMHO when computer was demoted from domain controller role it created local SAM database and didn’t use domain created accounts IUSR_ComputerName and IWAM_ComputerName.

Today I was solving problem with open relay Exchange server. I came to server and it was full of SPAM e-mail messages. I needed to clean all this mess from Submission queue. I used following command:

Get-Message -Filter {FromAddress -eq “<>”} -Server MAILSERVER | Remove-Message

That’s all folks 🙂

I had to solve interesting problem today at one of our customer. Here is a short preview of customer’s environment:

AD Topology

Customer has following 5 sites:

• Site1 – containing 1 DC
• Site2 – containing 1 DC (one has PDC FSMO role)
• Site3 – containing 2 DCs. Let’s call this central site.
• Site4 – containing 2 DCs. This site represents one datacenter (datacenter 1)
• Site5 – containing 2 DCs. This site represents one datacenter (datacenter 2)

All domain controllers are Global Catalogs. Replication was set manually. It’s configured to be in star topology with median in Site3. For each connection was defined newInter-Site Transport in AD Sites.

AD Topology

Replication works fine. Exchange servers are able to resolve all domain controler. I have checked this using DNS and also nltest.

Exchange Topology

There are four Exchange 2012 servers. Two are CAS/HUB servers put into CAS Array. CAS Servers and CAS Array IP addresses belong to Site4 IP Subnet. And two Mailbox server that are put into DAG. Both mailbox server and DAG IP addresses are in Site4. Problem is that one CAS/HUB and one Mailbox server are physically located in Site4 and one CAS/HUB and one Mailbox server are located physically in Site5. Between Site4 and Site5 are L2 networks for CAS/HUB and Mailbox server.

Exchange topology

Everything works fine. All IP subnets are assigned to Site4 which means all Exchange servers use primary Global Catalog functionality from domain controller from Site4. Idea from network/security guys was to allow Exchange servers to use Global Catalog just from domain controllers located in datacenters – Site4 and Site5. So firewalls don’t let Exchange server to use Global Catalog from other domain controller besides those located in Site4 and Site5.

Problem

Problem appeared when domain controllers in Site4 went down. Exchange servers didn’t want to start and mount databases.

When we looked into Events we could see event 2080 which stated that Exchange AD Topology service sees just four domain controllers:

• Two in-site domain controllers from same site IP subnet are in (Site4)
• Two out-of-site domain controllers. Controllers only from central site Site3

Exchange didn’t use those out-of-site domain controllers, because firewalls blocked it – regarding network/security guys recomendations. Question was why exchange servers didn’t see and use other domain controllers? It sees and uses only those four domain controllers (two in same AD site and two from central site).

After couple of minutes discusing with my coleague we find out that Exchange copies AD topology and it uses domain controllers in following way:

• Primary uses domain controllers in same site as Exchange services are located – in-site DC
• Secondary uses only domain controller which are directly replicating with domain controllers from primary site  – out-of-site DC

My colleague tried to convince me to believe it’s good idea and Exchange tries to protect you from some problems. But I don’t see any point of Exchange not contacting all domain controllers and contacing only domain controllers in the site and contacting domain controlers which replicate with domain controllers in site. I don’t see a poing of Exchange not trying to connect to Global Catalogs in Site1, Site2 and Site5. So this is the way Exchange looks for Global Catalog servers by design.

Proof of problem 🙂

I’ve done couple testing scenarios.

Exchange servers in Site4

• In-site DCs: DCs from Site4
• Out-of-site DCs: DCs only from Site3

Exchange servers in Site5

• In-site DCs: DCs from Site5
• Out-of-site DCs: DCs only from Site3

Exchange servers in Site1

• In-site DCs: DC from Site1
• Out-of-site DCs: DCs only from Site3

Exchange servers in Site3

• In-site DCs: DCs from Site3
• Out-of-site DCs: all DCs from all sites

This is really proof of problem with Exchange locating DCs.

Solution

To solve this issue we could make two things:

• Create new AD Site only for all Exchange IP Subnets and add two domain controllers into this new created AD Site. One DC would be located in physical location 1/datacenter 1 (with CAS1 and MBX1 servers) and other DC would be located in physical location 2/datacenter 2 (with CAS2 and MBX2 servers).

• Create new AD Inter-site Transport between Site4 and Site5.

We decided to create new AD Inter-site Transport.

I still don’t understand why Exchange doesn’t use all domain controllers in AD domain as I would think it would 🙁

Today one customer sent me an e-mail with a following problem. They wanted to use e-mail address microsoft@DOMAIN.TLD, but when they assigned this e-mail address to someone they received error that e-mail address is already in use.

Read more…

When I was checking events today at one of our customers I mentioned one weird event. It was:

Event 2070

Process MSExchangeMailboxReplication.exe () (PID=1388).  Exchange Active Directory Provider lost contact with domain controller OLD_DC_NAME.  Error was 0x51 (ServerDown) (Active directory response: The LDAP server is unavailable.).  Exchange Active Directory Provider will attempt to reconnect with this domain controller when it is reachable. 

Read more…