Month: August 2014

How to move a user database to a different location

Posted on Updated on

Here are a couple of ways to move the database files to a different location other than the default.

Using SSMS:

1.  Using the SQL Server Management Console, right-click on the database, go to Task and Detach.  You may also have to restrict access to the database to SINGLE_USER before you can perform the Detach if there is a process currently using it.  To set it to SINGLE_USER mode, right-click on the database, properties, Options and scroll down to Restrict Access.

2.  Once the database is detached, copy/move the data file (.MDF) and log file (.LDF) to the new location, and then Attach the database back.  Right-click on Databases, select Attach.  Hit Add on the Attach Databases window and then browse to the new data file (.MDF) location and select the database.  If the log file (.LDF) is located on a separate disk, then you will also have to specify the path for the log file under the Database details window.  Then hit OK.

Using T-SQL scripts with Detach:

1.  You can run the following scripts to Detach, copy/move the data files and then perform the Attach command.  I will use the TEST database with an example path.










( FILENAME = N’Z:\LOG\TEST_log.ldf‘ )



Using T-SQL Scripts with Alter Command:




— Please note that the EXEC XP_CMDSHELL command might not work if it is not enabled in your SQL server.  You will need to enable it first or you can substitute this command with manually copying/moving the data files.










Event 2028, MSExchangeIS Public Store, how to troubleshoot?

Posted on Updated on

Before I was able to figure out this issue, I have been receiving more than 100 of these alerts in Exchange.


The delivery of a message sent by public folder <publicfolder> has failed.





The non-delivery report has been deleted.


The event ID does not give you a lot of information and it is hard to figure out where this is coming from.

By default, mail-enabled Public Folders are not able to receive NDRs that is why you are seeing these alerts in the logs.

Here are the steps I took to figure out where the emails are being generated:

1.  Login to Exchange Management Console, open the Public Folder Management Console and drill down to the public folder mentioned in the event ID.

2.  Right-click on the public folder, properties, Mail Flow Settings, Delivery Options and then add an email address where you want all NDRs to be sent (All other emails are also forwarded just an FYI).  And DO NOT forget to check the box ‘Deliver message to both forwarding address and mailbox’ so that the regular emails are still being received on the mail-enabled public folder.

Once all settings above are setup, the NDRs will be forwarded to the email specified in the forwarding address field.  And the NDRs will give you all info you need as with a regular NDR.

In my case, the emails are being generated externally by our vendor and I had to quarantine the emails on our SPAM firewall so they no longer reach the Exchange Server.

I hope this helps.


I also added this same comment to the forum in


Exchange Logs filling up – what to do?

Posted on Updated on

Today, I noticed that one of our logs drives are filling up rapidly.  I was able to move the unused logs to a different drive but the logs continued to grow (check this link on how to move the unused logs

Here are some things you can do to figure out what is causing the logs to fill up:

1.  I just migrated 3 iPhone users yesterday to the mailbox and I thought they may be causing issues.  Confirmed with the users that they have not installed the latest IOS yet.  Here is an article from Microsoft that talks about that.

Rapid growth in transaction logs

2.  To confirm my suspicion, I downloaded EXMON ( from Microsoft and installed it on my Exchange Server.  And ran a trace to find out what user may be causing the issue.  And bingo, the 3 users I migrated last night showed in the top 5 users with the highest CPU usage and Log bytes.

You can either ask the users to update to the latest version of IOS or follow Microsoft’s recommendation in the link in step 1.

Note:  Also check the logs in your Exchange server for any errors.  I noticed that large amounts of NDRs with Event ID 2028 (MSExchangeIS Public Store) causes the logs to fill up in my case.



If you are getting this error when trying to re-launch EXMON, make sure that there are no processes running for this app.

From the command prompt, run logman query -ets to find out if ‘Exchange Event Trace’ is running.

Run the commands logman stop “Exchange Event Trace” -ets to stop

How to export a mailbox using Exchange PowerShell

Posted on Updated on

Here I am going to show you how to archive mailboxes to PST and how to deal with errors along the way.  When I first attempted the export in Exchange 2010, I ran across 2 error messages which prevented me from exporting a mailbox.  Below are the steps I performed to correct the issue.

1.  The very first step is to make sure the user running the export command have necessary permissions:

In Exchange 2010 ECP, go to Roles & Auditing and you may have to add a new Role called ‘Mailbox Import Export Role’ to the user.  Under Role Groups, select New, Enter the Name of the Role and you can set the scope to default.  Under Roles, add ‘Mailbox Import Export Role’ and under members, add the group or user who will be running the export command.

If the role is not setup before running the export, the process will have an error ‘Couldn’t find the Enterprise Organization container’.

2.  Next step is to create a share, preferably on the Exchange server to where all the archive emails will be saved.  Make sure to add FULL share and security permissions for Exchange Trusted Subsystem (normally found in your root domain – root\Exchange Trusted Subsystem) and SYSTEM.  If you are running the Information Store with a specific service account, then you will have to add that account too.

If the permissions are not setup correctly, an error will be displayed after running the export command: ‘Unable to open PST file ‘\\location\name.pst’.  Error details:  Access to the path is denied.

Note:  When I tried to google for an answer to this error message, I only came across articles suggesting to add the ‘Exchange Trusted Subsystem’ to the shared folder.  And unfortunately, it did not fix my issue.  I found the SYSTEM in all of my built-in Exchange shares and that is what lead me to the resolution.

3.  Export the mailbox by running the command:

New-MailboxExportRequest -Mailbox name -Filepath \\UNC_path_from_step_#2\name.pst

4.  After successfully running the export command, you can run the Get-MailboxExportRequest to see the status of the export.

I hope this article helps other users out there who are trying to export mailboxes for the first time.

How to free up Exchange log drive space when it fills up

Posted on Updated on

There are a couple of instances where I had to free up the log drive on our Exchange server because the drive is full.  This has happened to me multiple times even with alerting setup and do diligence.  There are just some disasters you cannot prevent – like your Marketing or Ebusiness department decided to send 50,000 campaign emails in an hour filling up your Exchange outbound queue and ended up filling up your log drives too.

When the log drive fills up, Exchange will also automatically dismount your mailbox database associated to the log drive to prevent database corruption.

First thing to do when this happens is CALM DOWN and DON’T PANIC!  You can be back up and working again in a matter of seconds.  Tell your boss not to stay behind you and breath on your neck while you resolve the issue :).

Here are the things I normally do when this issue happens:

1.  Login to the Exchange server and locate the checkpoint file in the log drive.  The checkpoint file has an extension of .CHK and normally starts with E0x.

2.  Run eseutil.exe /mk “path\name.chk” to find out what logs are still needed and what can be safely moved/deleted.  In my example below, I ran the command eseutil.exe /mk e04.chk while I am inside the logs directory.  The result will show you the checkpoint or last log that was committed.


3.  Based on the result, all logs previous to the checkpoint can be safely moved/deleted (I don’t recommend deleting just in case you need them back or you overlooked what files are still needed).

If your checkpoint file is e04.chk then your log files will start with e04 followed by 000 and then the checkpoint HEX.

Example:  e040001810F is the checkpoint log

All files starting with e040001810E and older can be safely moved to another location to free up space.

4.  Once the old log files are moved, go back to the Exchange Management Console and mount the mailbox database.  To save your users, you can immediately try to mount the database after freeing up a couple of megabytes on the log drive.   I would already try to mount the database if I see more than 200MB of freed space.  So your users can already login to their mailboxes while you are still freeing up more space.  And that will make the boss happy.

Note:  If you are unable to mount the mailbox database after the cleanup, make sure that the database is not corrupted.   This issue almost never happens but if it does happen to you, you may have to restore from backup or repair the database.

To prevent future issues, first let your Marketing or eBusiness group send the emails by batch if possible.  🙂 Or enable circular logging for the mailbox database which is by default turned ON.  Also, make sure that your Exchange backup is running successfully each night which will also truncate the logs for you.