Tag Archives: migration

Moving a small on-prem environment to Azure/ O365 – Part 1

This posting is ~3 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

It was a bit quiet here due to the current COVID 19 pandemic. But now I’m back with a pretty interesting story on how my colleagues and I moved most of our on-prem server stuff to Microsoft Azure and Office 365.

Microsoft 2020 (c)

It all started with the COVID19 lockdown in Germany in March 2020. We moved into our home offices after setting up a small VMware Horizon View deployment to access our PCs using physical View Agents and manual desktop pools. Most projects were stopped, and we did most of our work remote. No lay-offs or short-time work.

We were running a small VMware vSphere cluster for a couple of years. Nothing fancy: Two HPE ProLiants, vCenter, two DCs, File-/ Printserver, WSUS, Exchange, Linux maschines for web services, Sophos UTM, a pfSense, View Connection Server, UAG, ADFS/ ADFS Proxy, PKI etc. In sum 18 VMs on two hosts, some VLANs with firewalls in between etc. We were running Exchange 2016, AzureAD Sync, Exchange Hybrid, but we only used Microsoft Teams from our Office 365 deployment. Veeam Backup & Replication was used for backups, a backup copy to a NAS and some Robocopy jobs that moved Veeam Backups to USB drives for DR. Everything was pretty simple and designed to work without much operations. Our focus is on our customers, not on our internal IT. It was stable, secure and pretty slick.

In March 2020 we asked “What if?”. What if we lose our offices due to a fire (we are located in a bigger office building and we had a couple of fire alarms this year due to remodeling work). How can we work if your DSL line is cut? How can we get our backups offsite? How can we modernize our IT withtout big invests? Money, that we don’t spend on our internal IT can given to our employees. ;) (By the way, that’s the same reason why we try to drive smaller and more efficient cars…).

We developed a couple of ideas, including new servers, storage etc. and put that stuff into a datacenter. But in the end, we decided to move most of our stuff to Microsoft Azure and Office 365.

I want to share some of the things we have learned on the road to Azure.

Initial assessment

We used the Azure Migrate Server Assessment tool to assess our vSphere environment. We wanted to get a ball park on how we had to size the VMs. We knew, that we wont need to migrate all VMs. For example our virtual pfSense firewall, the vCenter, the Sophos UTM or our ADFS setup were not planned to migrate.

After the first assessment, we started to play around the the Azure pricing calculator. Just to get an idea on how different VM sizes affect the costs.

Subscription

As a Microsoft partner, we were able to use our internal user rights (IUR) for Microsoft Office 365 and Azure. Microsoft offers us 25 Office 365 E3 plans and a 6000 US-$ budget for Azure (Azure Sponsorship Subscription). Our plan was to stretch the Azure budget over 12 months, so that we don’t have additional costs until we re-apply for our Microsoft partnership. Starting with 6000 US-$ Azure budget, it makes ~16 US-$ per day for our complete Azure deployment.

Sizing

Now, as we knew that we have 16 US-$ per day, we planned our Azure deployment. First of all, we planned the number of VMs. We had 18 VMs on-prem, and we managed to get down to 9 VMs.

two Domain Controller
PKI
Fileserver
Management Server
Remote Desktop Host (all-in-one Deployment)
Ticket System
SQL/ App server
Exchange 2016 for Hybrid Deployment

The View Connection Servers and UAG are still running on-prem. Our virtual pfSense will be moved to a WatchGuard Firebox soon. Sophos UTM and ADFS are gone. A dedicated WSUS server is not necessary any more, we moved back to simple Windows Update and Delivery Optimization.

Instead of D-Series VMs, we decided to go for B-Series VMs. The main reason for this were costs, but today I can say: The performance is quite good. I can’t see any reason for us to move to D-Series.

To connect to our Azure deployment, we had to setup Site-2-Site VPN. We deployed a simple Gen1 Basic SKU VPN Gateway. We had no need for more than 100 Mbit (we’re using a 50/10 VDSL at our office location), BGP or zone redundancy.

Instead of Standard SSD or Premium SSD storage, most of our VMs are using simple Standard HDD storage.

Backups are kept in a Recovery Services Vault with pretty simple polices. Either a VM needs to be current, in this case we keep 7 restore points, or we might need to keep more restore points. In this case we keep 7 daily, 5 weekly, 12 monthly and 3 yearly restore points. And this is only the case for our fileserver.

Additional cost savings

But with this setup we would not get under 16 US-$ a day. :( So we took another approach to break the mark: We shut down VMs at night and at the weekends! It took a bit until my colleagues and I get used to this. Nobody wants to shut down servers without a good reason.

But: We are currently at 18 US-$ per workday, and 10 US-$ for saturday and sunday. Everything, except domain controllers and ticket system, is shutdown at night and on the weekends.

We are using an Automation Account with some simple scripts and schedules to shutdown VMs and start them again.

What’s next?

The next blog post will be around how we planned the usage of Office 365, and how we started with Azure.

HP Comware: Forwarding subnet-directed broadcasts for Wake-on-LAN

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Last week, my colleague Claudia and I have ported a HP ProVision configuration to HP Comware. Unexpectedly, it wasn’t routing or VLANs or OSPF that caused headaches, it was a Wake-on-LAN (WoL). Depending on the used tool, the magic packet (which wakes up the computer) is a broadcast (255.255.255.255) or a subnet-directed broadcast (e.g. 192.168.200.255). So it was important to know what tool the customer used.

This is how HP ProVision implements subnet-directed broadcasts:

ip directed-broadcast
ip udp-bcast-forward
vlan 99
     ip address 192.168.200.254 255.255.255.0
     ip forward-protocol udp 10.0.0.255 9
vlan 3
     ip address 10.0.0.254 255.255.255.0

The first two commands are issued globally. The “ip forward-protocol” statement has to be entered in the source VLAN (from which the magic packets are sent). The “ip forward-protocol” statement includes the protocol (udp), the destination (the broadcast address of the subnet) and the udp port (WoL uses port 9). Pretty simple, right? But please note that this config works only for sunet-directed broadcasts. And it only works for WoL. If you need another port (e.g. udp port 7), you have to add an additional “ip forward-protocol” statement.

If you use HP Comware, the configuration differs in some points. You can enable the reception of subnet-directed broadcasts by entering “ip forward-broadcast” globally in the system-view. This is mandatory.

<HP> system-view
[HP] ip forward-broadcast

The next step is to tell the switch, to which destination it should forward subnet-directed broadcasts. This can be done by entering “ip forward-protocol” in the vlan-interface context.

[HP-Vlan-Interface99] ip forward-broadcast

The downside: All subnet-directed broadcasts will be forwarded, regardless of source, destination or protocol. To avoid this, you have to create a ACL and add this to the “ip forward-broadcast” statement. To create an ACL enter:

[HP]acl number 3001
[HP-acl-adv-3001] rule 10 permit udp source 192.168.200.0 0.0.0.255 destination 10.0.0.255 0 destination-port eq 9
[HP-acl-adv-3001] quit
[HP] interface Vlan-interface 99
[HP-vlan99] ip forward-broadcast acl 3001

You have to bound the ACL to the source VLAN interface. The subnet-directed broadcast will be forwarded to the VLAN interface which is directly connected to the destination subnet, or if there is no directly connected interface, to a router which knows the way to the destination. If you have applied packet filter ACLs to VLAN interfaces, make sure that your forwarded subnet-directed broadcasts aren’t filtered!

How to migrate from VMware vCOps to vROps – Part 3

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

I wrote about what’s new in vROps 6 and about the deployment of the virtual appliance. I also described how to migrate the data from the old vCOps vApp. Part 3 covers the decommission of the old vApp.

Enter the IP or FQDN of your UI VM into the browser. Login as admin into the administration UI.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Before the vApp can be removed, the vCOps needs to be unregistered from the vCenter. Click “Unregister”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

A confirmation pop-up appears. Click “Yes”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The process can take some time, depending on your environment. In my case the unregistration took about 5 minutes.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

That’s it. After the successful unregistration, the vApp can be shutdown and removed from the vCenter. Say good bye and enjoy your new vROps 6.0!

EDIT

Some users complained about the absence of the Health Widget in the vSphere Web Client, after the removal of the old vCOps. Michael White (@mwVme) posted the solution: vSphere Web Client Health State Widget has errors after vR Ops Migration? Thanks to Michael for sharing this!

How to migrate from VMware vCOps to vROps – Part 2

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Part 1 of this series has covered a short overview over vRealize Operations Manager 6.0 and the initial deployment of the virtual appliance. Now it’s time to bring it to life.

Open a browser and enter the IP of your newly deployed vROps appliance. You will get this nice initial setup screen. “New Installation” is always a good start. Click “New Installation”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Within five little steps, the configuration of vROps will be done. You may have noticed the “Migrate Data” icon on the right of the screenshot. This will be important later. Start with clicking “Next”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Enter the password for the build-in administrator account and click “Next”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

I really liked part: Choose Certificate. No command line, no complex knowledge base articles. Simply choose “Install a certificate” and point the installer to a valid certificate. You can replace the certificate later. Because of this, I’ve chosen “Use the default certificate” at this point.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Enter the name of the master node and a valid NTP server. In my case, the NTP server is my Active Directory Domain Controller.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Complete the initial setup by clicking “Finish”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Now the vROps services must be started. Click “Start vRealize Operations Manager”. The pop up can be answered with “Yes”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Because I already had a vCOps running in my lab, I’ve chosen “Import Environment”. This selection allows you to import the data from your current vCOps vApp. Click “Next”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Carefully read the EULA, enable the checkbox and click “Next”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Now you have to add a license key. I used my vExpert vCloud Suite key.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Enter the IP address or the FQDN of your current vCOps UI VM. A pop-up appears that informs you, that an agent is pushed to the VM. This step takes about 5 minutes to finish. Click “Next”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

You can add additional solutions at this point. This wasn’t necessary in my case. Click “Next”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Everything’s fine. Simply click “Finish” and relax.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Now the data is imported. Depending on your resources and the amount of data, this step can take some time. In my case this step took about 10 minutes to finish.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Congratulations! That’s it. Easy, isn’t it? Now you can add additional nodes, e.g. a replica node or additional data nodes.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The migration process is really easy and straightforward. The database is the most valuable. Because of this, I strongly recommend to migrate the data from your current vCOps environment.

But what to do with the old vCOps vApp? It’s still active and consumes resources from your vSphere cluster. I covered this in part 3 of this series.

How to migrate from VMware vCOps to vROps – Part 1

This posting is ~8 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

VMware presented the vRealize Operations Manager 6.0 at the VMworld 2014 in Barcelona. In early december, vROps was available for download.

vROps 6.0 is the successor of VMwares IT Operations Management suite vCenter Operations Manager, or vCOps. VMware has aligned the naming scheme with other products, so this release is the first release under the new brand vRealize.

VMware has made some major improvements to this release. One of the biggest advantages is the ability to scale-out. In prior releases you had to deploy multiple vApps to scale. Now you can add additional vROps instances to a cluster. These appliances provide computing resources, as well as redundancy. This allows you to scale beyond the limits of vCOps 5. Redundancy is provided by a concept which is based on master, replica and data nodes. The fist node in a vROps deployment is the master node. By adding a replica node, you can add redundancy for the case that the master node fails. Master and replica node work in a active/ standby relationship. The data nodes are the secret behind the scalability of vROps. A data node has only one task to perform: Collect data based on the assigned adapter.

Abstract

An adapter is used to collect data from 3rd party systems and it’s provided by different available management packs. Check VMwares Whitepaper “VMware vRealize Operations Guide to Third-Party Solutions” for more information about availble management packs. From my point of view the management packs (which provide the adapters) for HP 3PAR (HP StoreFront), HP OneView, Brocade SAN Analytics, Microsoft SCOM or SAP CCMS are really cool. Just to make this clear: vRealize Operations Manager 6.0 is NOT focused on VMware! You can use vROps with available management packs to get a much better oversight over your IT infrastructure!

VMware has also improved the user interface (UI). There is no need anymore to switch between different UIs. The management, administration and customer UI has been consolidated into a single UI. The first UI access after the initial deployment is redirected to a first-time wizard. This wizard helps you to deploy vROps, or to migrate your vCOps environment. In addition to the UI changes, VMware has added RBAC to vROps to simplify user access management.

When talking about the UI, it’s only a small step to the data visualization and reporting. The visualization of collected data is one of the greatest features of vCOps/ vROps. Only data visualization makes it possible to get a quick oversight over the current health of the IT infrastructure. Prior version of vROps included reports and some fixed dashboards. With the current release, vROps provides fully configurable reports and dashboards with the ability to include any data source, object or metric. Just think about the opportunities: You can build reports or dashboards across the whole stack, from the infrastructure to the application.

Smart Alerts provide a way to trigger an alarm, when multiple symptoms are observed. This is much more flexible than the old alarms you know from vCOps. But even a dynamic threshold may be too inflexible in certain cases. Smart Alerts add more intelligence to the alarming system. When using smart alerts, an alert is triggert when multiple symptoms are observed. Now you know that something is wrong in your datacenter. But how can you solve this? vROps is able to execute basics operations as a reaction to a smart alert. If you need more advanced reactions, vROps can utilize vRealize Orchestrator to accomplish this. Your datacenter will heal itself.

The capacity management was improved. The well known “Demand & Allocation” based capacity model hasn’t changed, but it’s now not limited to vSphere objects. The capacity management can now include all monitored objects. VMware also improved the the “what-if”-analysis. This feature was now extended and is now aware of projects. With this feature, you can add future hardware purchases into a “what-if”-analysis.

VMware dramatically improved the analysis and monitoring of the storage subsystem. Unified Storage Visibility can show you the correlation between applications and your underlying storage infrastructure in an End-2-End manner.

The licensing was simplified. Customers can now install multiple editions in the same vROps deployment. This enables customers to deploy a-la-carte and suite licenses together, e.g. vCloud Suite Standard, vSOM Standard and vROps Standard together in one deployment. You can’t deploy Standard with either an Advanced or Enterprise, e.g. vCloud Site Standard and vSOM Advanced or vROps Advanced/ Enterprise.

The deployment process

You can deploy vROps using a virtual appliance or on top of RHEL or Windows using suitable installation packages. I would always prefer the appliance deployment. A big advantage is, that the new vROps appliance is a single appliance, not a vApp. Especially in environments without DRS deploying the vCOps vApp was pain. You can deploy vROps on every ESX/ESXi host running version 4.0 or later that is managed by a VMware vCenter Server 4.0 Update 2 or later.

I used the good old C# client to deploy the appliance. ;) Start with selecting “Deploy a OVF Template” from the vSphere client.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Simply click “Next” to get to the EULA.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Carefully read the EULA and click “Accept”. Then click “Next”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Enter a new name for the vROps appliance or accept the default name. Select a location for the VM.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Select the configuration. If your environment consists of equal or less 2000 VMs, select “small”. In this case the appliance will configured with 4 vCPUs and 16 GB memory. This is equal to the resources of the old vCOps vApp construct.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Select the host or the cluster into the vROps appliance should be deployed. I selected my management host.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Select a resource pool if you have RPs configured.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

I deploy my VMs always thin-provisioned in my lab. Select an appropriate disk format for your deployment.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Choose the port-group to which the appliance should be connected. In my case it’s my infrastructure port-group.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Now we need to add IP, subnet, gateway, DNS and time zone. Make sure that this applies to the port-group you have chosen one step earlier.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Double check your settings and click “finish”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Depending on your equipment, wait a couple of seconds, get yourself a coffee or go out for a walk. Congratulations, it’s a vROps!

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

At this point is the initial deployment finished and we can proceed further. As you maybe noticed, there was already a vCOps deployed in my lab. At this point a vCOps 5.8.x and a vROps 6.0 were running in my lab. Time to migrate vCOps to vROps. This process is covered in part 2 of this series.

Active Directory property ‎’homeMDB‎’ is not writeable on recipient

This posting is ~9 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

During an Exchange 2013 migration project the first attempt to migrate a mailbox failed with the following error:

Error: MigrationPermanentException: Active Directory property 'homeMDB' is not writeable on recipient 'testing.local/Users/Dummy'. --> Active Directory property 'homeMDB' is not writeable on recipient 'testing.local/Users/Dummy'.

The error message clearly stated, that this was a permission issue. A quick search pointed me to the right direction. I found a thread in the TechNet forums, in which the same error message were discussed. This error occurs, if the Exchange Trusted Subsystem group is missing in the ACL of the user object. This group contains the exchange server and it’s usually inherited from the domain object to all child containers and objects. I checked the ACL of the user and the Exchange Trusted Subsystem group was missing in the ACL. This was caused by the disabled permissions inheritance. An object ACL with disabled permissions inheritance is sometimes called a protected ACL. Bill Long wrote a nice Power Shell script to search for object which have permissions inheritance disabled.

How to enable permissions inheritance?

Start the Active Directory Users and Computers MMC. Click “View” and enable “Advanced Features”. Otherwise the needed tabs will not shown.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Open the user that can’t be migrated. Switch to the “Security” tab. Click “Advanced” and enable the “Include inheritable permissions from this object’s parent” check box. Click “OK” and confirm popups regarding added ACL entries.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Check if the Exchange Trusted Subsystem group is now part of the ACL. If yes, try the migration of the mailbox again.

Why is permissions inheritance disabled?

Good question, the customer asked me the same question. But the answer is easy. As above mentioned, is a ACL with disabled permission inheritance called a protected ACL. When should a ACL be protected? If the ACL of the associated object shouldn’t be changed, when a permission from a parent object is inherited. A good example for such an object is the Administrator account. Active Directory protects members of the following groups

Enterprise Admins
Schema Admins
Domain Admins
Administrators
Account Operators
Server Operators
Print Operators
Backup Operators
Cert Publishers

and the following users

Administrator
krbtgt

with three simple steps:

Set the value of the AdminCount attribute to 1.
Disable permission inheritance
Apply permissions from the AdminSDHolder template

This process runs once an hour on a Active Directory Domain Controller and recovers the ACL of the two user accounts and the member accounts of the mentioned groups to a protected state and well-known permissions. What happens if you add an user account to the Domain Admins group? AdminCount is set to 1, the permission inheritance is disabled and the permissions specified in the AdminSDHolder template are applied. If you remove the user account from the Domain Admins group, the changes are not rolled back and so permission inheritance stays disabled! Changes to parent ACLs are not applied to the user account and, in the case of my customer, the Exchange Trusted Subsystem group wasn’t added to the user objects ACL.

You can search for accounts with AdminCount=1 easily with the PowerShell:

PS C:\Users\Administrator> ([adsisearcher]"(AdminCount=1)").findall()

Path                                                        Properties
----                                                        ----------
LDAP://CN=Administrator,CN=Users,DC=testing,DC=local        {msexchrecipientdisplaytype, logoncount, codepage, objec...
LDAP://CN=Administrators,CN=Builtin,DC=testing,DC=local     {objectcategory, usnchanged, distinguishedname, grouptyp...
LDAP://CN=Print Operators,CN=Builtin,DC=testing,DC=local    {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=Backup Operators,CN=Builtin,DC=testing,DC=local   {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=Replicator,CN=Builtin,DC=testing,DC=local         {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=krbtgt,CN=Users,DC=testing,DC=local               {logoncount, codepage, objectcategory, description...}
LDAP://CN=Domain Controllers,CN=Users,DC=testing,DC=local   {usnchanged, distinguishedname, grouptype, whencreated...}
LDAP://CN=Schema Admins,CN=Users,DC=testing,DC=local        {objectcategory, usnchanged, distinguishedname, grouptyp...
LDAP://CN=Enterprise Admins,CN=Users,DC=testing,DC=local    {objectcategory, usnchanged, distinguishedname, grouptyp...
LDAP://CN=Domain Admins,CN=Users,DC=testing,DC=local        {objectcategory, usnchanged, distinguishedname, grouptyp...
LDAP://CN=Server Operators,CN=Builtin,DC=testing,DC=local   {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=Account Operators,CN=Builtin,DC=testing,DC=local  {iscriticalsystemobject, usnchanged, distinguishedname, ...
LDAP://CN=Read-only Domain Controllers,CN=Users,DC=testi... {usnchanged, distinguishedname, grouptype, whencreated...}

Why is this a problem? With AdminCount=1 and disabled permission inheritance you will face a lot of problems:

Changes to an object ACLs are rolled back after an hour
Send-As doesn’t work
ActiveSync doesn’t work
Language settings in Outlook Web Access isn’t saved
..and some other nasty effects

I have seen this error so often. Mostly at customers, that use normal work accounts for administrative tasks, or that add normal user accounts to admin groups during the setup of new profiles or clients. The solution is easy: Don’t do it!

Exchange 2013: Event ID 2937 MSExchange ADAccess after public folder migration

This posting is ~9 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

I got a couple of warnings (source MSExchange ADAccess, Event ID 2937) after removing a Exchange 2007 server at the end of a Exchange 2007 > 2013 migration. The details of the warning told me, that there was a faulty value set to a attribute of the mailbox database object. Because the public folder migration was part of the migration, the error message seemed plausible.

Process w3wp.exe (PID=4652). Object [CN=Mailbox Database E2K13,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Testing,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=testing,DC=local. Property [PublicFolderDatabase] is set to value [testing.local/Configuration/Deleted Objects/Public Folder Database DEL:4a45b7c2-10fc-42df-bdaa-82ae8a12e66e], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.

A quick check with ADSI Edit confirmed the message. To be honest: I made a mistake and searched for the attribute PublicFolderDatabase in the database object, but in the end I found the wrong entry as a value of the msExchHomePublicMDB attribute in the database object. It must be set to the distinguished name of the mailbox database that houses the public folder mailboxes. If you don’t have any public folders in your Exchange 2013 org, then you have to clear the value!

The solution

Start ADSI Edit (Start > Run > adsiedit.msc) and right click the “ADSI Edit”. Select “Connect to…”.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Open the configuration context.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Navigate to the database object, which is mentioned in the warning.

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Right click the database object and select “Properties” from the context menu. You can limit the number of attributes if you hit the “Filter” button and select “Show only attributed that have values”. Scroll down to the msExchHomePublicMDB attribute. Double click it and enter the complete CN of the mailbox database, that houses the public folder mailboxes (this is new with Exchange 2013!). If you have not public folders in your Exchange org, than you can clear the value!

Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Click “OK” and restart the Exchange Information Store service. After the restart, no new 2937 events should be logged.

EDIT

If you get the message “Your Administrator has made a change and requires you to restart Outlook” (or in german “Der Microsoft Exchange Administrator hat eine Änderung durchgeführt, die einen Neustart von Outlook erfordert”), check if event id 2937 is logged on the Exchange servers. I had several migrations where a removed public folder DB caused Outlook to throw the error message.