Here is a Powershell script you can use to quickly determine the total amount of space taken up by all of your Exchange database files (edb files) on an Exchange server. I’d like to note that this may not necessarily be a 100% accurate representation but is a great way to get a ballpark number without having to add the numbers up yourself, manually.
I noticed that I had no way to calculate the total amount of space being used by my Exchange databases the other day. And even after scouring through teh Googles I was unable to find what I was looking for quickly so I wrote this script up quick to fix that problem. Just copy the previous bit of code into a ps1 file with notepad and execute the script from your EMS. It is a super simple way to iterate through all the databases, save their sizes to a variable and then spit that variable out when it is complete.
Recently I ran into an issue with a Lync environment (2010) where Lync conversations were not being saved to the “Conversation History” folder in Outlook (2010). Luckily there is a quick way to fix this issue, through Exchange. From the reading that I have done it seems like the most common reason this occurs is when a user in your Exchange environment reaches or surpasses 1,000 combined folders and sub folders in their mailbox. The easiest way to check if a user has reached this threshold is to use the Exchange Management Shell to quickly take a look at their total combined mailbox folders using the following command.
(Get-MailboxFolderStatistics “user”).Count
Easy enough, often times this is enough to determine the cause. But I have taken this command one step further and wrapped it into a little script that will go through your Exchange environment and record all users that have reached this threshold and place their display name as well as the number of folders/subfolders into a csv file for an easier to reference. Here is the logic of the script.
That logic right there is very basic but will iterate over all mailboxes in the Exchange environment, grab those with over 1,000 folders/sub folders, place them into an array and output the array. This will take a while depending on the size of your environment, so feel free to let it run in the background. It is not a super intensive process, it just takes forever. To get this into a CSV file use the following Powershell command, I have this script name Get-Folders.ps1 in this example.
.\Get-Folders.ps1 | Export-CSV users.csv
That should be it. Not everybody will need this obviously but I found that it came in handy.
I had a strange issue come up recently where mail administrators were unable to allow Exchange to pick which mailbox database to place users into (I’m not quite sure what this feature is called so we’re going with automatic load balancing) when they were creating new user mailbox profiles. This feature essentially picks a database at random as a way to balance and spread out mailboxes among databases. Makes, sense to me. Anyway, I’m thinking we may have installed an update that changed the behavior because this feature had apparently been working up until we installed Rollup 5-v2. So it appears that this update had broken this automatic mailbox load balancing functionality, although I’m not 100% sure. I just wanted to mention it in case some of you are looking for clues as to why this is happening.
So here is what the error looks like when allowing Exchange to choose which database to use when a new user is initially created.
Error: Load balancing failed to find a valid mailbox database.
Hmm, okay. That is weird. You can check to see if the database is set to be allowed with this command.
get-mailboxdatabase | ft name,isexcludedfromprovisioning
In my case, all of my mailbox databases came back true, so they are unable to be used for automatically selecting a database when the user created. To fix this, go ahead and run the following.
Now go ahead and run the first command again and you should see that all the mailboxes are now marked as false, meaning they are now included in the provisioning process.
Now you should be able to go through and create without selecing a specific mailbox. My best guess is that the update must have set this flag to exclude these databases from provisioning but is weird and is worth mentioning because it happened to cause some seemingly unexplained issues for us.
Forgive the boring title for this post but I do think that this is a really important topic and one that I had to deal with recently at work. Somehow one of our Exchange mailbox databases became corrupted and one of our users lost a ton of email, which, I’m almost 100% sure was related to the outage catastrophe we experienced 1.5 weeks ago. This event made me thank the Flying Spaghetti Monster that I was getting good backups from our (sometimes shaky) backup solution, Data Protector. Anyway, for this topic I will just assume that you are getting backups from whatever backup solution but it isn’t all that important because the majority of this post will cover specific instructions for the procedure within Exchange, so you can take bits and pieces and apply them where you need to.
Before I go any further, it is always worth mentioning; make sure you are getting good backups!
Ok, now that we have that out of the way I will show you the basic restore procedure within the Data Protector environment. Select the Restore option from the drop down list -> MS Exchange 2010 Server.
Then select the source to backup up (Whichever database that needs to be restored). With in Data Protector specify the restore options that you would like.
These are the options I used most recently.
Restore method: Restores files to temporary location
Backup version: Whichever data you decide you need to roll back to
Restore chain: Restore only this backup
Target client: Select the mailbox server that you want to restore to
Restore into location: This can be any location, just make sure there is enough disk space.
Select Restore databse file only
Once you have chosen your restore options, click the restore button to begin the restore procedure.
Once the database has been restored with Data Protector
Now for the fun stuff. This is the part that I’m guessing most will probably be concerned with, but I didn’t want to leave out my Data Protector peeps. Open up an Exchange Management Shell on the mailbox server that you restored your database to. Technically it can be from any server as long as you connect to the correct mailbox server I guess. Anyway, rename your restored database to something like “recoverydb.edb”. Change directories into the restore folder, then check the status of the newly restored database with the following command:
eseutil /mh recoverydb.edb
You should see something similar to the following:
If it shows Clean Shutdown you can skip ahead. Since we didn’t bring any log files down with us in this restore we will need to run the database hard repair on this database using the following command:
eseutil /p recoverydb.edb
After running the repair you should get a clean shutdown state if you check again (eseutil /mh).
Now we need to create a recovery database for Exchange to use in order to recover this data from.
It is important that when you create your recovery database it matches the renamed .edb file. So since I renamed my recovery database to recoverydb.edb, I used recoverydb in the Powershell command. If you want to check to make sure this step was done properly, use the following command to verify that the database is roughly the size you are expecting it to be:
After everything looks good we mount our database.
Mount-Database recoverydb
Just to verify that the database has stuff in it and we can find the person we’re looking for, we will take a quick look at the database contents, as shown below.
Get-MailboxStatistics -Database recoverydb
It looks like there are users there so all we need to do now is dump their emails into a temporary/recovery account in Exchange with the following command:
-RecoveryMailbox is the user mailbox that we are pulling data from, the source mailbox
-Identity is the user mailbox that we are putting data into, the destination mailbox
-RecoveryDatabase is our newly created recoverydb
-TargetFolder is the a folder that we will create on the target user to house the recovered items
-Verbose optional debugging information if there is a problem anywhere in the process
The wording and syntax of this command is a little bit tricky. Just remember that the -RecoveryMailbox signifies the backup location and the -Identity signifies the restore location. After this process completes (could take awhile depending on the mailbox size) you should be able to log in to the temporary account and take a look at the newly created “RecoveredItems” folder in which the mailbox contents of the user mailbox we are restoring have been copied in to.
Once this is done, just right click the target mailbox (temporary_account), click Manage Full Access Permission and give the restore mailbox (user_to_recover) full permissions through the Exchange Console so you can copy over messages, etc. in Outlook.
This step can be done any number of different ways but I chose this method because I was more concerned about the safest way to do this. You could, for example, copy the contents directly into the user mailbox if you wanted. Another option would be to export the contents of the temporary user out into a .pst file, with something like the following:
That should be it, after you are done and the emails have all been recovered , be sure to dismount the recovery database and delete the files to free space back up on your mailbox server.
I’d like to talk quickly about a great and underutilized method for troubleshooting email flow problems. Today I had to rebuild an Exchange Hub Transport server after a slight catastrophe from last week in which the VM the Hub lived on was completely unrecoverable. That is another story but it brings up the need for using a great tool that is often skipped over, and that is sending test email via telnet.
The reason I say that this method is underutilized is because, well who uses telnet these days? What’s great about using this is that you can test different aspects and essentially pinpoint where mail flow issues are occurring. In my case I was have trouble relaying email from an internal account to outside mail servers. So let’s jump into how to use this tool, its easy but I feel like not enough people know about it, so here we go.
First, since I was testing from inside, I need to connect to the local server name.
telnet hubserver.psa.local 25
Easy enough, we are using telnet to connect to the hub server, hubserver.psa.local on port 25 (SMTP). Once we get in we run a simple,
ehlo
That gives us back a little bit of information, basically telling us that this is an email server and some of its capabilities. Next, we will need to run through the following set of commands to send out the test email. It is important that these commands are entered in exactly, with no backspaces, otherwise it will break the command and you will get an error message spit back out from your telnet session.
RCPT TO: Tells the mail server the email address that is being sent to.
[email protected] is the address we are sending to. It can be any of your internet based mail addresses (google, yahoo, etc.).
DATA signifies the start of the message body.
SUBJECT: This line is optional, probably a good idea to include a subject so the message doesn’t get blocked or sent to spam. Hit enter twice after this to drop into the message content.
message content is whatever you want to include in your message. Follow your message by hitting enter.
“.” (read dot) on a line by itself will tell the mail server to end the message and send it. It is basically the equivalent of an escape character for emails.
QUIT leaves the telnet session from the mail server.
It is important that the previous set of commands is run the way that they look. This whole string of commands should look something similar to the following inside of your shell when things are all said and done, assuming everything is working properly.
In my case, I was unable to enter an address for the RCPT TO: command. To fix this, among with a few other steps in rebuilding the hub was to grant anonymous send permission on the Exchange side of things, then after that mail began flowing through the newly rebuilt Hub Transport server perfectly.
That should be it, I highly suggest going through the process of sending out a few test emails to get this method stuck in your brain for later on down the road if you ever have to do any mail flow type troubleshooting. Good luck!
