After installing Exchange 2013 SP1, I began reviewing the server’s Application log for errors or warnings. There were a large number of Event ID 2937, from MSExchange ADAccess, and while the exact error text varied a bit from event to event, they all indicated that an Exchange property was pointing to a deleted object in AD. The process itself can vary, as can the property in question. In our case it was [PublicFolderDatabase] as shown below.

While researching the issue I was able to find a bit more information about properties other than [PublicFolderDatabase]; in some cases this error seems to indicate missing or bad data that must be corrected for Exchange to function properly. Our specific error wasn’t causing any operational problems but it was littering the Application log.

What I found strange after doing some research was that the PublicFolderDatabase property is deprecated in Exchange 2013 and thus shouldn’t be causing a problem. Nonetheless, the data was still there and I needed to remove it. Unfortunately with the property deprecated, Set-MailboxDatabase could not be used to set PublicFolderDatabase to $null; attempting to do so resulted in “Cannot validate argument on parameter ‘PublicFolderDatabase’. The argument is null or empty…”

The other info I could find out there called for using ADSI Edit to remove the property, but try as I might I couldn’t find the PublicFolderDatabase property where the App log said it should be. Finally I stumbled on this post which, while not pertaining specifically to Exchange 2013 identified the actual attribute name as “msExchHomePublicMDB”. I still couldn’t find it though until I read this comment, which explained the problem: I had been viewing the properties of the “notebook” object, rather than the “folder” object. (See screenshot below)

Once I opened the properties of the folder object, sure enough I found “msExchHomePublicMDB” and was able to clear it out. Once replication occurred, the errors stopped. Simple fix once you know where to look.

If you have a single domain, odds are you prefer that your users can log on to Outlook Web Access without having to enter the domain name, which many of them probably don’t even know anyway. For the actual OWA login page, this is simple; See this link for info on changing the default domain property.

Unfortunately, the default domain setting does not apply to the form that allows you to change an expired password. Notice how the login screen only asks for “User name:” but the change password screen asks for “Domain\user name:” And sure enough trying to change a password without using the domain will simply not work. The fix for this is actually simple although it’s a bit of a hack; be careful.

On your Exchange server (presumably your CAS server; we’re in a single-server environment), navigate to {Exchange Install Path}\V15\FrontEnd\HttpProxy\owa\auth\15.0.847\scripts\premium and find fexppw.js. I’m not sure if the “15.0.847” directory will change with patches or service-packs; this is what ours is on Exchange 2013 SP1.

Open the file, and find the below lines:

// Fill in username, set focus to password
//
gbid(“username”).value = rg[3];

Change the last line to:

gbid(“username”).value = “domain\\” + rg[3];

Now the user name field will correctly populate the domain name and your users should no longer need to enter it in order to reset their password.

With Exchange 2013, Microsoft made changes to how it approaches updates and patches. Essentially, every few months there are what would have previously been termed update roll-ups, which are now called cumulative updates (CU). Each CU however is a full build of Exchange 2013, rather than a collection of patches. The same holds true for the recently released Exchange 2013 SP1; this isn’t a service pack in the traditional sense, it’s once again a full build of Exchange. That doesn’t mean you can’t upgrade over your existing Exchange 2013 install, but this isn’t a patch you can push through WSUS.

Our SP1 upgrade started poorly. Almost immediately, during the prerequisite check, we received the following error:

Following that link resulted in a completely useless page indicating that Microsoft hadn’t yet added any info about that error message. Gee, thanks. Searching the web didn’t turn up anything relevant either, hence this post.

I used Sysinternals Process Monitor to try and determine what application(s) were using eseutil. It turned out our backup application was doing so, but even after stopping the backup and disabling the service, the files remained open. Looking further, I found Volume Shadow Copy (VSC) also using eseutil. I disabled that, along with my anti-virus for good measure, but the files stayed open. I ended up rebooting the server with my backup app and VSC disabled, and that allowed me to move forward.

The upgrade itself went fine and conveniently once the process starts no user interaction is required. You do need to manually reboot the server once the install is done, and I found Exchange took a bit longer than normal to get started after the reboot, but other than that things seem fine.