Exchange Server Pro » Solutions

Show Full Free/Busy Details for Exchange Server 2010 Room and Resource Mailboxes

Paul Cunningham — Sun, 06 May 2012 13:35:48 +0000

In the comments of my article about Exchange Server 2010 Room mailboxes some readers wanted to know how they can configure the Room mailbox to show more details about existing meetings in the free/busy information that is revealed to other users on the network.

Consider the scenario where a room is booked, and perhaps another person wants to contact existing meeting organizers to ask if they can remove a booking to make room for a more important one, but the free/busy information (as seen in the Outlook Scheduling Assistant) doesn’t indicate who made the bookings.

This is caused by the default permissions on the mailbox’s calendar. These default permissions are set to show only the availability information (eg free, busy, tentative) but not any other details.

In the calendar permissions (if you were modifying them via Outlook) it would look like this.

If viewed in the shell it with Get-MailboxFolderPermission it would appear like this.

[PS] C:\>Get-MailboxFolderPermission homeetingroom1:\Calendar

RunspaceId   : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName   : Calendar
User         : Default
AccessRights : {AvailabilityOnly}
Identity     : Default
IsValid      : True

If you modified the permissions using Outlook the new permission level of Reviewer would allow other users to see more details about existing meetings.

You can apply that same permission in the Exchange Management Shell using the Set-MailboxFolderPermission cmdlet (note: Set-MailboxFolderPermission modifies an existing entry, whereas Add-MailboxFolderPermission would be used to add a new entry to the permissions).

Set-MailboxFolderPermission homeetingroom1:\Calendar -User Default -AccessRights Reviewer

The results can be seen in the Get-MailboxFolderPermission output.

[PS] C:\>Get-MailboxFolderPermission homeetingroom1:\Calendar

RunspaceId   : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName   : Calendar
User         : Default
AccessRights : {Reviewer}
Identity     : Default
IsValid      : True

RunspaceId   : 8706cde4-2cb5-4519-9a46-a46fcc0c450c
FolderName   : Calendar
User         : Anonymous
AccessRights : {None}
Identity     : Anonymous
IsValid      : True

When creating a new meeting request users are now able to see more details about the meeting organizer.

You can modify all the default permissions on Room mailboxes with the following commands in the Exchange Management Shell.

[PS] C:\>$rooms = Get-Mailbox -RecipientTypeDetails RoomMailbox
[PS] C:\>$rooms | %{Set-MailboxFolderPermission $_":\Calendar" -User Default -AccessRights Reviewer}

Get more Exchange Server tips at ExchangeServerPro.com

Dealing with Exchange Server Update Rollups and Forefront Protection for Exchange

Paul Cunningham — Mon, 23 Apr 2012 13:41:32 +0000

When Microsoft recently released the latest update rollup for Exchange Server 2010 a few disgruntled customers left comments about the situation with Exchange update rollups and Forefront Protection for Exchange.

If you’re not a Forefront user or you’re otherwise unaware of the situation, the issue is that Forefront Protection for Exchange and update rollups don’t play nicely together. For example during installation the update rollup can hang at stages such as restarting the Exchange services after the update has been applied.

Services not starting after Exchange Server rollup installation

This is why each update rollup release comes with the following instructions:

Note for Forefront Protection for Exchange users For those of you running Forefront Protection for Exchange, be sure you perform these important steps from the command line in the Forefront directory before and after this rollup’s installation process. Without these steps, Exchange services for Information Store and Transport will not start after you apply this update. Before installing the update, disable ForeFront by using this command: fscutility /disable. After installing the update, re-enable ForeFront by running fscutility /enable.

As a result we see comments like these from disgruntled customers.

Note for Forefront Protection for Exchange users: We still don’t care enough about you to add two lines to the setup script. Instead you have to do it manually. Or you can install the update via Microsoft Update and you’ll be in for a funny surprise.

Hey Microsoft…. could you not detect for your own software and automatically run the command fscutility /disable????, Now I cannot even get WUS to do this…. Annoyed! and feeling unappreciated as a FF customer

Microsoft actually has provided a solution for this, back when Exchange Server 2007 SP2 was released, and appears to have carried it forward for Exchange Server 2010 as well. A script named CustomPatchInstallerActions.ps1 can be used to perform pre- and post-installation tasks for update rollups.

I’m not sure why they don’t refer to it with each update rollup release, but as far as I can tell from my own testing it works fine.

Here is what you need to do.

In the \Scripts folder of your Exchange 2010 installation find the file named CustomPatchInstallerActions.ps1.template
Create a new sub-folder in \Scripts named Customizations
Copy the script template into that sub-folder, and remove the .template extension
Edit the file with the customizations you want, and the next time you install an update rollup the script will be called automatically

So what kind of customizations should you include? I did a little testing and here is what I suggest as a minimum. You’ll also find Microsoft’s advice here.

First, I ran fscutility /disable (from the C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server folder) to see what happens. I received the following output.

Error:
  Microsoft Forefront Protection cannot be disabled at this time.  Please stop
  the following services and then rerun this utility.

   FSCController
   MSExchangeTransport
   MSExchangeIS

So clearly some services need to be stopped first. That will need to go in the script.

After disabling those services fscutility /disable works successfully. So that can be run second.

  Removing dependencies...

      dependency on FSCController removed from Microsoft Exchange Information Store
      dependency on FSEIMC removed from Microsoft Exchange Transport Service
      Microsoft Exchange Transport Service Agent registration removed

Status:  Microsoft Forefront Protection NOT Integrated.

In the custom script itself the actions to perform before installing an update rollup go in the PrePatchInstallationActions function.

function PrePatchInstallActions
{
                Log "Running PrePatchInstallActions"

		Log "Stopping services"
		Stop-Service FSCController,MSExchangeTransport,MSExchangeIS -Force

		Log "Disabling Forefront"
		$fscutility = "C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server\fscutility.exe"
		Invoke-Expression $fscutility /disable

}

Notice I’ve also made use of the Log function that is in the script so that I can see in the log file later that my custom actions were run (or at least attempted to run). The log file is written to C:\ExchangeSetupLogs\CustomPatchInstallActions.log

After the update rollup is finished installing there is a similar process involved to re-enable Forefront. These steps go in the PostPatchInstallActions function.

function PostPatchInstallActions
{
                Log "Running PostPatchInstallActions"

		Log "Stopping services"
		Stop-Service FSCController,MSExchangeTransport,MSExchangeIS -Force

		Log "Enabling Forefront"
		$fscutility = "C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server\fscutility.exe"
		Invoke-Expression $fscutility /enable

		Log "Starting services"
		Start-Service FSCController,MSExchangeTransport,MSExchangeIS

}

When I upgraded two servers side-by-side, one with the CustomPatchInstallerActions.ps1 and one without, the one with the script updated without any problems and the one without hung while trying to start the services afterwards.

So in my testing this appears to work well, but it is something you should test in your own environment before relying on it too heavily.

Note that this script can be used for all kinds of situations even when Forefront is not installed. If you have any pre- or post-install actions required in your environment (eg running the StartDagServerMaintenance.ps1 script, disabling backups, disabling other antivirus software, sending an email alert to your team) you can include those in this CustomPatchInstallerActions.ps1 script.

Get more Exchange Server tips at ExchangeServerPro.com

The User Hasn’t Logged on to Mailbox So There is No Data to Return

Paul Cunningham — Fri, 23 Mar 2012 13:05:05 +0000

A reader asks:

I have been trying to get a script that can log into mailboxes automatically. The reason is that I have 500 mailboxes and when I attempt to query their statistics I get an error that the mailbox has never been logged into and therefore can’t generate any stats.

Let’s take a quick look at the issue itself. When a new mailbox is created and you attempt to use Get-MailboxStatistics to query the mailbox, you will receive a warning similar to this.

WARNING: The user hasn’t logged on to mailbox ‘exchangeserverpro.net/Company/Branch Office/Users/Blake Johnson’
(’0971ff8e-d6d1-4bd6-98b9-384b35103a2d’), so there is no data to return. After the user logs on, this longer appear.

In itself this is not a problem, but it might produce undesirable results for some mailbox reporting tasks, or at the very least make them a little more difficult.

The idea of creating a script that automatically logs on to new mailboxes is one approach to solving the problem. However it is probably more difficult than another solution which is also available.

That other solution is to simply send the mailbox an email. Once you do that the Get-MailboxStatistics cmdlet will return a result for the mailbox like this:

[PS] C:\>get-mailbox blake.johnson | Get-MailboxStatistics | ft -auto

DisplayName   ItemCount StorageLimitStatus LastLogonTime
-----------   --------- ------------------ -------------
Blake Johnson 1                 BelowLimit

But is it practical to send 500 mailboxes an email? If it is a test lab you could simply add them all to one distribution group, and send that group an email. It would take just a few moments.

If it is a production system and new mailboxes are created regularly, you can automate the task. MVP Pat Richard has written a PowerShell script that can be run as a scheduled task to automatically send a welcome email to new mailboxes. You can customize the welcome message to provide useful information to new users on the network. It really is a great idea if you ask me, plus it solves this issue with mailbox reporting. Check out Pat’s script here.

Get more Exchange Server tips at ExchangeServerPro.com

PowerShell Script to Generate Email Traffic in a Test Lab Environment

Paul Cunningham — Mon, 19 Mar 2012 12:50:57 +0000

For a long time now I’ve wanted to write a script that would automatically generate email traffic within an Exchange Server test lab environment.

Having realistic email traffic within a test lab environment means you can do such real world activities as:

test backup and recovery scenarios
learn how to use message tracking logs
test archiving solutions

In the past I’ve used some simple VBScripts that just sent random messages via SMTP as a way to fill up test lab mailboxes. That approach had some disadvantages though. The scripts I wrote only sent a stream of email messages at a single rate rather than at varying rates through the day as you would see in the real world. They also filled up inboxes only, never putting the messages in the Sent Items folder for the From address.

So last week I got to work creating a new PowerShell script to generate the email traffic. I tracked some of the development in the forums and can now share the complete script here.

This script does require some setting up before you run it, so please read the instructions to get it working in your test lab. I have only written and tested this script for Exchange 2010 training lab environments on the assumption that most people will be training for the latest version of Exchange.

Before we go further let me be absolutely clear that this script is for test lab environments only. Under no circumstances should you attempt to run this script in a production environment.

Using the Start-MailGen.ps1 Script in Your Test Lab

The scripts uses the Exchange Web Services Managed API so the first step is to download and install that on your test lab server.

EWS Managed API

Next, download the script and extract the three files to your server. I placed mine in C:\Scripts\MailGen.

Download the script file here: Start-MailGen.ps1 (downloaded 286 times so far)

Open the Start-MailGen.ps1 file in the PowerShell editor or in Notepad and check the following items.

The $dllfolderpath variable is set to the default installation path for the EWS Managed API v1.1. If you install a different version, or to a different path, update this variable.

#Path to the Exchange Web Services DLL
$dllfolderpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"

The script uses a switch statement to determine how many emails to send each hour of the day. These values are what I use but you can change them up or down to suit your test lab. The hours 6am to 7pm are individually specified, and then the default value at the end is used for the remaining hours of the day.

06 {$sendcount = 50}
07 {$sendcount = 80}
08 {$sendcount = 600}
09 {$sendcount = 600}
10 {$sendcount = 800}
11 {$sendcount = 1000}
12 {$sendcount = 600}
13 {$sendcount = 600}
14 {$sendcount = 800}
15 {$sendcount = 800}
16 {$sendcount = 900}
17 {$sendcount = 400}
18 {$sendcount = 200}
19 {$sendcount = 80}
default {$sendcount = 10}

You can just specify even numbers like the above because the script varies the send count further by adding a random number each time. This will give you a realistic level of email traffic through the different hours of the day.

Sample email traffic graph

The service account that will be running the script needs impersonation rights granted to it. I run mine as Administrator since it is just a test lab. Open the Exchange Management Shell and run the following command to grant the impersonation rights.

[PS] C:\>New-ManagementRoleAssignment -Name:impersonationAssignmentName -Role:ApplicationImpersonation -User:administrator

You may also need to set your script execution policy to unrestricted.

[PS] C:\>Set-ExecutionPolicy Unrestricted

Also, as the script file was downloaded from the internet you may need to right-click the file and choose Properties, and then click the Unblock button.

The script also depends on the Active Directory remote administration tools. These should be installed already on an Exchange 2010 mailbox server, but if you’re running the script from a non-Exchange server you may need to install them.

Finally, to start generating email traffic open the Exchange Management Shell and run the script.

[PS] C:\Scripts\Mailgen>.\Start-MailGen.ps1

The script begins to send email and will show a progress indicator.

Start-MailGen.ps1 running

The script will select a random sender and recipient from the available mailboxes in your test lab environment, and then construct a random email message using the two files that are provided with the script.

After sending the applicable number of emails for that hour of the day the script will sleep for 5 minute blocks until it reaches the next hour, and will start sending again.

You can leave the script running for several days if you wish, or set it as a scheduled task to ensure that it starts up again if the server is rebooted.

Get more Exchange Server tips at ExchangeServerPro.com

You Can’t Add the First Passive Copy of a Mailbox Database While Circular Logging is Enabled

Paul Cunningham — Sat, 10 Mar 2012 11:51:29 +0000

On an Exchange 2010 server when you attempt to add a mailbox database copy you may receive an error:

Database “MB-BR-01″ has circular logging enabled. You can’t add the first passive copy of a mailbox database while circular logging is enabled. Please disable circular logging before adding the first passive copy of this mailbox database.

Error adding first database copy

This error will occur if you’re trying to add the first database copy for a mailbox database that already has circular logging enabled.

Circular logging enabled for a mailbox database

The reason this occurs is that circular logging operates in two different modes depending on whether the mailbox database has copies or not.

Circular logging for non-replicated databases (just referred to as “circular logging”) operates in a constant state of log files being written, closed, and overwritten.

Circular logging for replicated databases (known as Continuous Replication Circular Logging, or CRCL) operates differently. With CRCL a log file is written, closed, and then needs to be shipped to the other DAG members that hold a replica of that database and replayed into their copy of the database as well. It is only when the reply has occurred on all other replicas that a log file is removed.

So, in order to add the first database copy for a mailbox database that has circular logging enabled, you must first disable circular logging by unticking the box or running the following Set-MailboxDatabase cmdlet the Exchange Management Shell.

Set-MailboxDatabase mb-br-01 -CircularLoggingEnabled $false

The database must then be dismounted and remounted for the change to take effect. After this you can add the database copy as originally intended.

After the first database copy has been added you can re-enable circular logging if you wish.

Set-MailboxDatabase mb-br-01 -CircularLoggingEnabled $true

Unlike a mailbox database with no additional copies, you can enable circular logging for a mailbox database that has copies in a DAG without dismounting and remounting the database.

As a final word, note that a similar issue will occur if you have CRCL enabled for a mailbox database and try to remove the last database copy. In that situation you will need to disable circular logging, remove the last copy so that only the standalone database exists, and then re-enable circular logging again if you wish.

Get more Exchange Server tips at ExchangeServerPro.com

How to Remove the Default Public Folder Database for an Exchange Mailbox Database

Paul Cunningham — Wed, 29 Feb 2012 11:36:55 +0000

Microsoft has made it pretty clear in recent years that public folders will be going away at some stage in the future of Exchange Server.

If you’ve been using public folders in your Exchange organization and decided to get rid of them completely then you may run into this particular issue.

In this scenario I have gone ahead and prepared to remove the public folder database by:

Removing all of the public folder content
Ensured OAB distribution is set to web only
Ensured all my clients are Outlook 2007 and above

When I attempt to remove the public folder database I receive this error.

The public folder database cannot be deleted

The public folder database ‘PF-BR-01′ cannot be deleted.

PF-BR-01

Failed

Error:

Public folder database “PF-BR-01″ is the default public folder database for the following mailbox database(s):

MB-BR-01

. Before deleting the public folder database, assign a new default public folder database to the mailbox database(s).

The solution seems logical. All I need to do is modify that mailbox database so it no longer uses the public folder database.

It is simple enough to change the public folder database configured for a mailbox database to some other public folder database, but in this situation I’m trying to get rid of public folders entirely. So instead I want to set the mailbox database to have no default public folder database.

Here is what happens if I try to use Set-MailboxDatabase to set the value to $null.

[PS] C:\>Set-MailboxDatabase MB-BR-01 -PublicFolderDatabase $null
Cannot validate argument on parameter 'PublicFolderDatabase'. The argument is null or empty. Supply an argument that is
 not null or empty and then try the command again.
    + CategoryInfo          : InvalidData: (:) [Set-MailboxDatabase], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Set-MailboxDatabase

It doesn’t work. However all is not lost, there is another way, using ADSIEdit.msc.

Open ADSIEdit.msc and connect to the Configuration naming context.

Connect to the Configuration naming context with ADSIEdit

Navigate to the container that holds the Exchange databases. For Exchange 2010 you’ll find this in CN=Services -> CN=Microsoft Exchange -> CN=(your organization name) -> CN=Administrative Groups -> CN=Exchange Administrative Group (FYDIBOHF23SPDLT) -> CN=Databases.

Right-click the mailbox database you want to remove the default public folder database from and choose Properties.

Scroll down until you find the msExchHomePublicMDB attribute. Highlight it and then click Edit.

Click the Clear button so that the value changes to “not set”.

Click OK, and OK again to commit the change.

Depending on the size of your network you may need to wait for that change to replicate throughout your Active Directory.

When you try to remove the public folder database again you should find that it now removes without error.

Public folder database successfully removed

Get more Exchange Server tips at ExchangeServerPro.com

How to Configure a File Share Witness for an Exchange 2010 Database Availability Group

Paul Cunningham — Mon, 20 Feb 2012 11:19:11 +0000

In my Exchange Server 2010 lab environment I unwittingly created a problem for the Database Availability Group. In preparing to consolidate all of the server roles onto just two servers and implement a hardware load balancer I went ahead and decommissioned the two CAS/HT servers that previously made up the CAS array in the site.

Naturally one of those CAS/HT servers also happened to be the File Share Witness for my two-member DAG. Whoops!

Now my DAG displays a warning when I check the health of it.

WARNING: Database availability group ‘dag-headoffice’ witness is in a failed state. The database availability group requires the witness server to maintain quorum. Please use the Set-DatabaseAvailabilityGroup cmdlet to re-create the witness server and directory.

In this real world this situation may also arise if the server hosting the File Share Witness was being decommissioned, or if it had failed. Fortunately we can resolve the problem by specifying a new FSW for the DAGm which I will demonstrate here.

I’m going to use another member server within the site as my FSW, which allows me to demonstrate a related problem. The server is named HO-MGT so using the Set-DatabaseAvailabilityGroup cmdlet to configure the FSW would mean I run this command.

[PS] C:\>Set-DatabaseAvailabilityGroup dag-headoffice -WitnessServer ho-mgt -WitnessDirectory C:\DAGFSW

However in this case I get an error.

WARNING: The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server
ho-mgt.
WARNING: Insufficient permissions to access file shares on witness server ‘HO-MGT.exchangeserverpro.net’. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: Access is denied
Unable to change the quorum for database availability group dag-headoffice. Witness server ‘\\HO-MGT.exchangeserverpro.net\dag-headoffice.exchangeserverpro.net’ network name wasn’t found. This may be due to firewall settings.
+ CategoryInfo : InvalidArgument: (:) [Set-DatabaseAvailabilityGroup], DagTaskProblemC…ptionBadNetName
+ FullyQualifiedErrorId : 75321C4E,Microsoft.Exchange.Management.SystemConfigurationTasks.SetDatabaseAvailabilityGroup

If you were running the same command but specifying another Exchange 2010 server to be the FSW you would not receive that error. This is because Exchange servers trust each other to perform this type of administration, thanks to a group called Exchange Trusted Subsystem.

All of the Exchange 2010 servers have this group as a member of their local Administrators group, for example here the local Administrators group of one of my DAG members.

Exchange Trusted Subsystem group in local Administrators

So the solution is to add the Exchange Trusted Subsystem group to the local Administrators group on my HO-MGT server, and then run the Set-DatabaseAvailabilityGroup command again.

After running the command you can see that Exchange has created the folder and shared it on the FSW server, no need to manually create the folder or set any permissions yourself.

Database Availability Group File Share Witness directory

Now when checking the health of the Database Availability Group you should not receive any warnings about missing File Share Witness servers.

Get more Exchange Server tips at ExchangeServerPro.com

Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports

Paul Cunningham — Mon, 06 Feb 2012 12:05:54 +0000

One of the Exchange Server administration tasks I perform almost every day is creating mailbox size reports. There are a few different reasons that I create these reports, such as planning a mailbox migration project, responding to a storage capacity alert for a particular database, or providing a specific team of people with a report of their mailbox sizes.

Now it is pretty easy to get the sizes for Exchange mailboxes and to handle the formatting of the Exchange 2010 mailbox statistics so that they are easier to perform calculations on, but it gets a bit boring running those commands day after day.

Even worse, after running the commands to create a CSV report I still had to open that in Excel, remove the unwanted details, use Excel formulas to convert the values from bytes to megabytes, sort them into order, and so on. Again not difficult, just boring after doing it hundreds of times.

So I created a PowerShell script, Get-MailboxReport.ps1, to do all of the heavy lifting for me, and I’m sharing that script with you here.

Download the script file here: Get-MailboxReport.ps1 (downloaded 3537 times so far)

Let’s take a look at how the script works. Here if a video to demonstrate:

I’ve included help information within the script itself so you can use Get-Help to discover how to run the script.

[PS] C:\Scripts\demo>Get-Help .\Get-MailboxReport.ps1

NAME
    C:\Scripts\demo\Get-MailboxReport.ps1

SYNOPSIS
    Get-MailboxReport.ps1 - Mailbox report generation script.

SYNTAX
    C:\Scripts\demo\Get-MailboxReport.ps1 [-database ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-file ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-server ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-mailbox ] []

    C:\Scripts\demo\Get-MailboxReport.ps1 [-all] []

DESCRIPTION
    Generates a report of useful information for
    the specified server, database, mailbox or list of mailboxes.
    Use only one parameter at a time depending on the scope of
    your mailbox report.

RELATED LINKS
    For more script details, a video demo, or to give feedback please go to:

http://exchangeserverpro.com/powershell-script-create-mailbox-size-report-exchange-server-2010

REMARKS
    To see the examples, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -examples".
    For more information, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -detailed".
    For technical information, type: "get-help C:\Scripts\demo\Get-MailboxReport.ps1 -full".

Depending on which parameter you use the output will vary.

If you use the -mailbox parameter to query a single mailbox, then the output will appear in the console window. I don’t really see the need to output a single mailbox’s details to a CSV file.
If you use any of the other parameters, -server, -database, -file, or -all, the output will be written to a CSV file in the same folder you’re running the script from.
You can use the optional -filename parameter to specify your own output file name

Once you’ve generated the CSV report you can open it with Excel and begin to analyze the data.

Download the script file here: Get-MailboxReport.ps1 (downloaded 3537 times so far)

Change Log:

6/02/2012 – V1.0 – Initial version
27/02/2012 – V1.1 - Improved recipient scope settings, exception handling, and custom file name parameter.

Get more Exchange Server tips at ExchangeServerPro.com

Avoid Running Out of Transaction Log Disk Space on Exchange Servers

Paul Cunningham — Sat, 28 Jan 2012 12:45:12 +0000

Paul Robichaux’s recent Windows IT Pro column contains this passage:

If you don’t know when you’re about to run out of disk space on the log LUN, you’re totally doing it wrong. It leaves me slack-jawed with astonishment that in 2012 we still have administrators who suffer unplanned downtime due to log volumes filling up because of poor design or problems with backups. Stop the madness! Check your backups regularly and use monitoring, be it however primitive, to ensure that you don’t have this problem.

Paul is referring to this post on the MS Exchange Team blog, which mentions that:

…the number one reason why our Premier customers open Exchange 2010 critical situations is because Mailbox databases dismount due to running out of disk space on the transaction log LUN.

Either I missed that post when it was published a few months ago or I glossed over it and it didn’t catch my attention enough.

I’ve been stung by transaction log disks running out of space, even as recently as last year. I work in a very large Exchange environment where backups and storage monitoring are performed by two different teams, both of them outside of my team.

That puts us in the situation where failed backups, combined with either a storage monitoring problem or a human error in the escalation processes can (and has) caused a log volume to fill up. Another situation that can arise is when new servers are provisioned, our help desks begin putting mailboxes on them before they’ve been added to the backups.

Which is why I wrote this script to check the Exchange database backups and alert my team when they have not been backed up in the 48 hours or more. In fact that script is a better version than the one we run in production (I haven’t ported over the improvements I later made at home to the original).

Ever since we put it in place that script has alerted us to numerous situations before they could evolve into disasters.

Setting it up as a scheduled task to run daily is a job that will take you less than half an hour. I highly recommend it, not just because I wrote the script, but because it adds a valuable layer of protection to your environment.

Get more Exchange Server tips at ExchangeServerPro.com

Error: Outlook Was Unable to Recover Some or All of the Items in this Folder

Paul Cunningham — Wed, 14 Dec 2011 10:13:26 +0000

While attempting to restore items from the Outlook recoverable deleted items you may encounter the following error message.

Outlook was unable to recover some or all of the items in this folder. Make sure you have the required permissions to recover items in this folder, and try again. If the problem persists, contact your administrator.

The error may occur when you attempt to recover a folder that contains a large number of sub-folders or mail items in it.

On the Exchange Server you may see a corresponding Application event log entry similar to this:

Log Name:      Application
Source:        MSExchangeIS
Date:          11/14/2011 12:57:59 PM
Event ID:      9646
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      exchangeserver.domain.local
Description:
Mapi session "3bbea118-07e3-4746-b7bf-0e5b65e28314" exceeded the maximum of 500 objects of type "objtFolder".

This can occur due to the default limits configured on the Exchange Server for the number of items that can be opened by a single MAPI session. In the example above the MAPI session was trying to open more than the default 500 allowed objects of type “objtFolder” (in other words, Folders).

The solution is provided by Microsoft in this support article, which refers to Exchange Server 2003 but applies to later versions as well.

Open Regedit and navigate to \\HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
If the key “MaxObjsPerMapiSession” does not already exist, right-click on ParametersSystem and create a new key of that name.
Create a new DWORD value with a name matching the object type in the event log error on your server (eg “objtFolder” in this example)
Set the DWORD value to a decimal value higher than the default. For the case above I first tried 1000, then 10000 when that did not work.
Wait 15-30 minutes for the registry change to take effect, then retry the Outlook operation.

You may find that you need to try gradually increasing the value until you can successfully recover the items in Outlook. You may also find that after you’ve removed one limit that another object type’s limit may also suddenly come into play, so always check your event log for new errors identifying additional object types that you may need to add a registry value for.

After you’ve successfully recovered the Outlook items revert the registry keys to their default values (listed in the Microsoft support article above) to prevent issues with server resources in the future.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » Solutions

Show Full Free/Busy Details for Exchange Server 2010 Room and Resource Mailboxes

Related posts:

Dealing with Exchange Server Update Rollups and Forefront Protection for Exchange

Related posts:

The User Hasn’t Logged on to Mailbox So There is No Data to Return

Related posts:

PowerShell Script to Generate Email Traffic in a Test Lab Environment

Using the Start-MailGen.ps1 Script in Your Test Lab

Related posts:

You Can’t Add the First Passive Copy of a Mailbox Database While Circular Logging is Enabled

Related posts:

How to Remove the Default Public Folder Database for an Exchange Mailbox Database

Related posts:

How to Configure a File Share Witness for an Exchange 2010 Database Availability Group

Related posts:

Get-MailboxReport.ps1 – PowerShell Script to Generate Mailbox Reports

Related posts:

Avoid Running Out of Transaction Log Disk Space on Exchange Servers

Related posts:

Error: Outlook Was Unable to Recover Some or All of the Items in this Folder

Related posts: