Uninstall Cannot Continue Database Public Folder Database Contains Folder Replicas

This time around I'll write about all the steps I used for a successful Exchange 2007 to 2013 migration in a small size company (about 40 users). I'm not quite sure (yet) if we will do the upgrade to 2016 directly afterwards, however I'll make a new 2013 to 2016 migration blog post if we decide to do so. At this point I can also state that it is impossible/not supported to do a migration from Exchange 2007 to Exchange 2016 directly, at least without 3rd party software. You can have a look at the "migration chart" at https://technet.microsoft.com/en-us/library/ms.exch.setupreadiness.e16e12coexistenceminversionrequirement%28v=exchg.160%29.aspx for example. If you want to pay extra money and go directly from 2007 to 2016 it should be possible with CodeTwo Exchange Migration, http://www.codetwo.com/blog/migrate-legacy-2003-or-2007-exchange-to-exchange-2016/ for example.

Anyways, onto the migration stuff itself. As always you should start with the homework. This time I don't have that many sources for you – instead some quality ones which gets the job done properly. Start off by reading:

• Upgrade from Exchange 2007 to Exchange 2013
• Planning and migrating a small organization from Exchange 2007 to 2013

The second link is awesome! Read it slowly and carefully. You'll be a lot smarter in the end. Lots of stuff to think of, but very nicely written.

I didn't follow the guide exactly to the word (as usual), but I couldn't have done the job without it. Some changes for our environment:

• We do not use TMG. All TMG steps were bypassed and were replaced by similar steps according to our own firewall policies.
• We have a Linux postfix server that handles all incoming email. It also handles antivirus and spam checking of emails. After these checks are done, it forwards email to the Exchange server.
• Storage configuration / Hard drive partitions / Databases weren't created the same way as in the guide.
• Certificates were renewed by our "certificate guy". No need for complicated requests etc.
• No stress tests and/or analyses were done. No need.
• Configured recipient filtering (there's a chapter about it).
• A script which deletes old IIS and Exchange logs was introduced (there's a part written about this also).

My own steps for the migration process:

On the old server:

• Patched Exchange Server 2007. Also installed the latest Update Rollup (21). You should have a fully patched (old)server before installing/introducing a new Exchange Server in the domain.

• Took screenshots of all current configurations (just in case). Most of the settings will migrate however. Stuff to backup are nicely documented in the above homework-link.
  • Namespace
  • Receive connectors
  • Send connectors
  • Quotas
  • Outlook Anywhere, OWA, OAB, EWS, ActiveSync settings
  • Accepted domains
  • Etc.. etc. that would be of use
• Got a new certificate which included the new host legacy.domain.com
• Installed the new certificate (on Exchange 2007 at first):

• Didn't use Exchange Environment Report/Exchange Profile analyzer or other tools to inspect current load and so forth. We have plenty of hardware power so the new server was set up based on the old specifications (with a little more CPU power and hard drive space). I would probably use all the tools available if upgrading/migrating in a larger environment however.
• Checked Offline Address Book settings on the Exchange 2007 server. They were OK. http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part8.html
• Active Directory Domain and Forrest levels were OK.
• All clients were OK (all Outlook 2013).
• Configured/Checked Outlook Anywhere settings – http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part8.html.

On the new server:

• Installed a new server, Windows Server 2012 R2.
  • Ran Windows update to fully patch it.
  • Had a look at the prerequisites: https://technet.microsoft.com/en-us/library/bb691354%28v=exchg.150%29.aspx
    • First two prerequisites were already installed by default (on a fully patched Windows 2012 R2 server):
      • Windows Management Framework 4.0
      • NET Framework 4.5.2
    • Next in line was RSAT-ADDS:

• Moving on to the other prerequisites:

• …and as a last prerequisite Unified Communications Managed API 4.0 Runtime , default installation.
• That's it for the prerequisites.

Moving on to the actual Exchange installation

• Had a look at my partition table, just to check that everything looked OK. (it did):

• The partition layout should be quite self-explanatory so I won't comment on that. I will however tell setup to use the existing partitions. I actually resized the partitions a bit after this screenshot…
• Once again following information from the excellent guide, I used the latest CU as installation source (NOT the installation DVD/ISO).
  • Downloaded the latest CU from https://technet.microsoft.com/en-us/library/jj907309%28v=exchg.150%29.aspx
  • Installed AD Schema updates and prepared Active Directory + prepared the domain:

• Actual installation (note paths for DB and Logs):

• Done. Moving over to post-installation steps

Post-installation steps

• Checking and changing the SCP. This should be done asap after the installation.

          Checking SCP.

          Changing SCP.

• Everything looks good!
  • If you are migrating/installing in a very "busy" environment, have a look at this Set-AutodiscoverSCP v2 script
• Next, we'll install the new certificate on the Exchange 2013 server:

           A simple "import" will do the job.

• Also have a look at the certificate in IIS (and change to the new one if necessary):

• With everything going smoothly, I continued configuring according to the guide http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part12.html
  • Did not configure External Access Domain (not configured on the old server either).
  • Changed all URLs for ECP, EWS, ActiveSync, OAB using my "backup-configurations/screenshots" I made earlier.
  • As a last configuration option I changed Outlook Anywhere:

Following the guide you should change the authentication to NTLM:

"As Outlook Anywhere is the protocol Outlook clients will use to communicate with Exchange Server 2013, replacing MAPI/RPC within the LAN, it's important that these settings are correct – even if you are not publishing Outlook Anywhere externally. During co-existence it's also important to ensure that the default Authentication Method, Negotiate, is updated to NTLM to ensure client compatibility when Exchange 2013 proxies Outlook Anywhere connections to the Exchange 2007 server".

• Moving over to the send and receive connectors.
  • The send connector automatically "migrated" from the old server.
  • The receive connector did NOT migrate from the old server. This is because Exchange 2013 use different roles for transportation compared to 2007. 2007 included only Hub Transport, but Exchange 2013 use both Hub Transport and Frontend Transport. For those of you interested in this change, read http://exchangeserverpro.com/exchange-2013-mail-flow/ and http://exchangeserverpro.com/exchange-2013-configure-smtp-relay-connector/ for example.
  • The CAS receives mail on port 25 and forwards it to the "backend" mailboxes that listens on port 2525.
  • I left the "Default Frontend servername" with its default settings:

• …and configured a new SMTP relay-connector which has "our settings". This connector has to be "Frontend Transport". You cannot create a new connector as Hub Transport. You'll be greeted by an error message if you try:

Information about this can be found at:

http://markgossa.blogspot.fi/2016/01/bindings-and-remoteipranges-parameters-conflict-exchange-2013-2016.html
http://exchangeserverpro.com/exchange-server-2013-upgrade-fails-due-to-receive-connector-conflicts/

"If you want to create a new receive connector that listen on port 25, you can do this but you have to create it using the Frontend Transport role if you have either an Exchange 2016 server or an Exchange 2013 server with both the CAS and MBX roles installed on the same server".

All our University email (and this specific company's email) is received via a Linux postfix server. This server handles all spam filtering and antivirus. After these checks are done, the mail is delivered/forwarded to Exchange.

After these steps were done, I continued with:

• Configuring mailbox quotas to match those on the old server.
• Configuring the Offline Address Book to be stored on the new server.
• Checking the log locations – should the transport logs be moved to another location or left at the default location? I changed them so they will go to the log-partition. In the end, this is just a small percentage of all logs generated. All other non-transport logs gets filled under C:\Program Files\Microsoft\Exchange Server\V15\Logging. I'm using a PowerShell script to delete all logs older than 30 days, and the same goes for the IIS logs in C:\inetpub\logs. The script looks like this, and is run via Task Scheduler daily:

$DateToDelete = 30
$StartFolder = "C:\Program Files\Microsoft\Exchange Server\V15\Logging"
$Year = (Get-Date).Year
$Day = Get-Date
Get-ChildItem $StartFolder -Recurse -Force -ea 0 | where{!$_.PsIsContainer -and $_.LastWriteTime -lt (Get-Date).AddDays(-$DateToDelete)} | ForEach{Add-Content -Path "Delete Log $Year.log" -Value " $_.FullName"; Remove-Item -Path $_.FullName }
$DateToDelete = 30
$StartFolder = "e:\Logs"
$Year = (Get-Date).Year
$Day = Get-Date
Get-ChildItem $StartFolder -Recurse -Force -ea 0 | where{!$_.PsIsContainer -and $_.LastWriteTime -lt (Get-Date).AddDays(-$DateToDelete)} | ForEach{Add-Content -Path "Delete Log $Year.log" -Value " $_.FullName"; Remove-Item -Path $_.FullName }
$DateToDelete = 30
$StartFolder = "c:\inetpub\logs"
$Year = (Get-Date).Year
$Day = Get-Date
Get-ChildItem $StartFolder -Recurse -Force -ea 0 | where{!$_.PsIsContainer -and $_.LastWriteTime -lt (Get-Date).AddDays(-$DateToDelete)} | ForEach{Add-Content -Path "Delete Log $Year.log" -Value " $_.FullName"; Remove-Item -Path $_.FullName }
exit

And the command to run from task scheduler:

• PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& 'D:\pathtoyour\scripts\clearlogging.ps1′"
  • Runs daily at 03:00

As you've probably noticed from my Exchange installation screenshots, I already pointed the Transaction logs to a different partition in the installation phase (E:\Databases\DB1). These logs don't need manual deletion however, they get deleted via the backup solution automatically (Veeam). The key here is that the backup software has to be Exchange aware . The other logs at e:\ are the Transport logs (E:\Logs), which are only a tiny part of the whole logging structure (C:\Program Files\Microsoft\Exchange Server\V15\Logging) in Exchange. You could leave the Transport logs in their default location though, as the above script will go through that directory also…

Recipient filtering / Stopping backscatter

As a nice bonus, Exchange 2013 can now handle recipient filtering (filter out non-existent users) properly. For more information about recipient filtering read:

https://technet.microsoft.com/en-us/library/bb125187%28v=exchg.160%29.aspx
http://exchange.sembee.info/2013/mbx/filter-unknown.asp
https://www.roaringpenguin.com/recipient-verification-exchange-2013

The filtering CAN be done without an Exchange Edge server even though Internet will tell you otherwise. We enabled it on our postfix server following tips found on https://www.roaringpenguin.com/recipient-verification-exchange-2013. Installation on the Exchange-side on the other hand looked like this:

I also enabled Anonymous users on the "Default receive connector":

Happy days! We can now filter out non-existent users on Exchange rather than manually on the postfix server.

I also checked that recipient filtering was active and working:

Yes, it was 🙂

With all this done I now moved forward with the configuration. Again, following http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part13.html

Getting ready for coexistence

I'll start off by copy/pasting some text.

"With our database settings in place and ready to go, we can start thinking about co-existence – before we do though, it's time to make sure things work within Exchange 2013! So far we've got our new server up and running, but we've still not logged in and checked everything works as expected". Source: http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part13.html

With this information in mind, I started testing according to the above link. The chapter of interest was "Testing base functionality". All tests passed. Very nice 🙂

With all tests done, and all users aware of the migration, I did the following after work hours:

• • Asked the "DNS guy" to make a CNAME record for legacy.domain.com pointing to the old server.

  • Changed all virtual directories on the old server to use the name "legacy".

    • Things to remember:

      • No external url for Microsoft-Server-ActiveSync.

      • Autodiscover Internal URL / SCP record on both Exchange 2007 and Exchange 2013 server should point to the new server.

  • DNS records are changed to point to the new server.

    • autodiscover and the namespace –record

  • Had a look at the send connector. Everything seemed OK. (Settings were migrated from the old server). However, minor change:

    • Removed the old server from the "source servers" and added the new server. New mail should be sent from the new server (and not from the old one anymore):

• postfix was also configured to route mail to the new server instead of the old one.

• Done. Next in line is moving/migrating mailboxes to the new server. Yay.

Migrating mailboxes

I started out by following the guide at http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part15.html , more specifically the part about "Pre-Migration Test Migrations". I moved a couple of test users and after that I sent and received mail to/from these users via Outlook and OWA. No errors were noticed, so I moved over to the real deal and started moving "real" mailboxes. Again, nothing special, I continued following the information at http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part16.html. I did a batch of 10 users at first (users A to E) and all of them were successfully migrated:

(The remaining mailboxes were also successfully migrated).

Upgrading Exchange AD Objects

Now it was time to upgrade the AD Objects following information from http://www.msexchange.org/articles-tutorials/exchange-server-2013/migration-deployment/planning-and-migrating-small-organization-exchange-2007-2013-part16.html.

The first two objects didn't need an upgrade, they were apparently already automatically upgraded during the migration process. The distribution group in the screenshot that needed an upgrade is a mailing list/distribution group.

Public Folders

The old environment didn't use public folders so luckily there were no need to migrate these. I did run into some problems with Public Folders however. More information in the chapter below.

Problems

• Everything seemed fine, BUT after a couple of days one user didn't see any new mail in a delegated mailbox she had. She also got the dreaded password prompt every time she started Outlook.
  • Later I heard that also other users were prompted for password
• This got me thinking about authentication methods. I've seen this before. A couple hours of googling still had my thoughts in the same direction, authentication methods.
• I still wonder why all of this happened though, knowing that ALL mailboxes were now hosted on the new Exchange 2013 server. Why on earth would someone's Outlook even check for things on the old server? Maybe some old Public Folder references etc. perhaps? Don't know, the only thing I do know is that it had to be fixed.

Some links about the same dilemma (almost, at least):

http://ilantz.com/2013/06/29/exchange-2013-outlook-anywhere-considerations/
https://gonjer.com/2016/07/02/outlook-prompts-for-credentials-with-exchange-2010-and-20132016-coexistence/
http://blogs.microsoft.co.il/yuval14/2014/08/09/the-ultimate-guide-exchange-2013-and-outlook-password-prompt-mystery/ (L. Authentication Issue)
http://silbers.net/blog/2014/01/22/exchange-20072013-coexistence-urls/

The thing is, I had authentication set to "NTLM" on the new Exchange 2013 server during the coexistence, following the very same guide as with almost everything else in this post. The NTLM setting should be "enough" afaik. One thing that wasn't mentioned in the guide however, was how the old server was/should be configured. I'm quite sure there are many best practices for Exchange 2007 also, but I myself hadn't installed that server in the past. Well, hours later, comparing different authentication methods, I finally think I got it right. Here's the before and after:

Before: old server IISAuthenticationMethods were only Basic.

Solution: Adding NTLM to IISAuthenticationMethods (on the legacy server)

After: NTLM added

I also removed the "Allow SSL offloading" from the new server for consistency. Not that I know if it helped fixing the problem or not.

You get kinda tired from all testing and googling, but hey, at least its working as it should and users aren't complaining anymore! 🙂

• Shared mailbox dilemma. When you send a message from the shared mailbox, the sent message goes into your own Sent Items folder instead of the shared mailbox sent items.

"If the shared mailbox is on Exchange 2010 and only has the Exchange 2010 sent items behavior configured, the settings are not converted to the equivalent Exchange 2013 settings during migration. You will need to manually apply the Exchange 2013 sent items configuration. It is probably best to do that before moving the mailbox. The Exchange 2010 settings are retained though". Source: http://exchangeserverpro.com/managing-shared-mailbox-sent-items-behaviour-in-exchange-server-2013-and-office-365/

• Well, no wonder my settings didn't stick when migrating from 2007 to 2013. I configured the correct settings again:
  • Get-Mailbox mysharedmailbox | Set-Mailbox -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true

Decommission Exchange 2007

Still following the guide, it was now time to decommission the old Exchange 2007 server. First off I left the server turned OFF for a week. No problems were encountered, so I decided to move on with the real decommissioning work.

• Didn't need to touch any TMG rules (obviously, since we don't use TMG)
• Removed unused Offline Address Books (OAB)
• Removed old Databases
  • Mailbox Database removal was OK.
  • Public Folders were a whole different story. What a headache. I followed almost every guide/instruction out there. Did NOT WORK. I got the "nice" message: " The public folder database "ExchangeServer\Storage Group\Public Folder Database" contains folder replicas. Before deleting the public folder database, remove the folders or move the replica to another public folder database ". God dammit. We've never ever been using Public Folders. Well, luckily I found some useful "fixes" after a while. Some "fixes" that MS won't mention. Solutions:

    http://www.sbsfaq.com/?p=3862 (use this fix btw, so you won't have to double fix it as me).
    https://oddytee.wordpress.com/2014/03/13/manually-remove-exchange-2007-public-folders-after-hybrid-migration/
    https://blog.dargel.at/2012/01/19/remove-public-folder-using-adsiedit/
    https://www.petenetlive.com/KB/Article/0000227

  • Removed CN=Configuration,CN=Services, CN=Microsoft Exchange, CN={organisation name i.e First Organisation}, CN=Administrative Groups, CN={Administrative Group name}, CN=Servers, CN={servername}, CN=Information Store, CN={Storage Group Name}, CN={Public Folder Database Name} with ADSIEdit (after I had backed up the key with help from http://www.mysysadmintips.com/windows/active-directory/266-export-active-directory-objects-with-ldifde-before-performing-changes-with-adsi-edit for example).
  • Ran the Get-MailboxDatabase | fl name,pub* –command again, but to my surprise the damn Public Folder Database wasn't gone. Instead it was in the AD "Deleted Objects". FFS, it CAN'T be this hard removing the PF Database (reference).
  • Trying to get rid of the deleted object with ldp didn't work either: "The specified object does not exist". I was getting even more frustrated.
  • Well, at least now according to EMC I have no active Mailbox Databases. That's good news, so I can now remove the Storage Groups even though this annoying PF DB reference still exist in AD. I can live with it for now, and hopefully when the Tombstone Lifetime expires, so will this PF DB reference. (That wasn't the case however, continue reading)
• Removed Storage Groups, FINALLY:

• No need for Arbitration / system mailbox migrations (as with Exchange 2010 –> 2013 migration). More info here for example:
  • https://msundis.wordpress.com/2010/03/29/show-and-move-hidden-arbitration-mailboxes-in-exchange-server-2010/
    • checkup on the new server:

• System mailboxes are already on the new server. Good.
• Uninstalled Exchange 2007 from control panel.
  • At least I tried. Of course there were problems. Again.

Got some tips from https://social.technet.microsoft.com/Forums/exchange/en-US/6469264a-dc33-4b07-8a7c-e681a0f9248f/exchange-setup-error-there-was-a-problem-accessing-the-registry-on-this-computer?forum=exchangesvradminlegacy. Solution was simply to start the Remote Registry service. It now uninstalled nicely.

• Well, apparently the Public Folder dilemma was a problem. The dead link pointing to "Deleted Objects" in AD was causing one user to get the dreaded "The Microsoft Exchange Administrator has made a change…" prompt. Oh my. Well, even more ADSIEdit fixed the problem (msExchHomePublicMDB attribute). Solution: https://exchangemaster.wordpress.com/2014/07/11/legacy-public-folder-remnants-in-exchange-2013-cause-the-microsoft-exchange-administrator-has-made-a-change-prompt/ and/or http://exchangeserverpro.com/remove-default-public-folder-database-exchange-mailbox-database/ (Actually same solution as in the first link about public folder dilemmas above). These solutions DID work however:

• Removed legacy DNS entries
• Firewall guy was informed that the server was decommissioned and all its firewall rules could be removed.
• Turned off the server and archived it.
• Happy days. No more Exchange 2007.

Security hardening

I always aim to keep my servers secure. This one was no exception, so I was aiming for at least a grade A on the Qualys SSL Labs test, https://www.ssllabs.com/ssltest/. I followed the guide from https://scotthelme.co.uk/getting-an-a-on-the-qualys-ssl-test-windows-edition/ and voilà, grade A was achieved  🙂 I left the HTTP Strict Transport Security policy alone for now however, it will need some more testing.

wolfordmenturn.blogspot.com

Source: https://sysadminblogger.wordpress.com/tag/the-public-folder-database-contains-folder-replicas-before-deleting-the-public-folder-database-remove-the-folders-or-move-the-replicas-to-another-public-folder-database/

Share this post