Month: August 2014
Here are a couple of ways to move the database files to a different location other than the default.
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.
ALTER DATABASE TEST
WITH ROLLBACK IMMEDIATE;
EXEC MASTER.DBO.SP_DETACH_DB @dbname = N’TEST‘
CREATE DATABASE [TEST] ON
( FILENAME = N’Y:\DATABASE\TEST.mdf‘ ),
( FILENAME = N’Z:\LOG\TEST_log.ldf‘ )
Using T-SQL Scripts with Alter Command:
ALTER DATABASE [TEST] SET OFFLINE
WITH ROLLBACK IMMEDIATE
— 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.
EXEC XP_CMDSHELL ‘COPY “C:\OLD_LOCATION\TEST.mdf” “Y:\DATABASE\TEST.mdf“‘
EXEC XP_CMDSHELL ‘COPY “C:\OLD_LOCATION\TEST_LOG.ldf” “Z:\LOG\TEST_log.ldf“‘
ALTER DATABASE [TEST] MODIFY FILE (NAME = ‘TEST‘, FILENAME = ‘Y:\DATABASE\TEST.mdf“)
ALTER DATABASE [TEST] MODIFY FILE (NAME = ‘TEST_log‘, FILENAME = ‘Z:\LOG\TEST_log.ldf‘)
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 https://wikipinoy.wordpress.com/2014/08/18/how-to-free-up-exchange-log-drive-space-when-it-fills-up/).
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.
2. To confirm my suspicion, I downloaded EXMON (http://www.microsoft.com/en-us/download/details.aspx?id=11461) 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
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.
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.