Exchange 2007 - Finding Users with Items Over nnn Days - Inbox

Finding the age of Inbox

I am currently working on a migration from an in-house Exchange 2007 infrastructure to a hosted environment. As part of this move, there are new restrictions being placed on the mailboxes. One of these restrictions is that all mail over 180 days old is automatically deleted from the system. Prior to migrating the mailboxes, I need to know how many and which users have items older than 180 days.
Finding this information was a two-step process:

1. Export all of the mailbox folder statistics to a CSV file
2. Scrub the resulting data with Excel to get a list of the users and their departments with mail items over 180 days old

The first part of this process was to export the folder statistics for each mailbox. I accomplished this using a combination of PowerShell cmdlets:

get-mailboxdatabase | get-mailbox -resultsize unlimited | get-mailboxfolderstatistics -folderscope all -includeoldestandnewestitems | export-csv mailbox_stats.csv

The cmdlets break down this way:

• get-mailboxdatabase fetches each database (this infrastructure employs multiple databases)


• get-mailbox runs through each mailbox in the current database


• get-mailboxfolderstatistics returns specifics about the folders in the mailbox. -folderscope all returns information about each folder under the top of information store and -includeoldestandnewestitems includes the dates of the oldest item in the folder and the newest item in the folder


• export-csv obviously exports the results to a CSV file

Once the information is in the CSV format:

1. I used a filter on the OldestItemReceiveDate field with "before" criteria for 180 days prior to the cut-off date


2. Once I had the list of results narrowed down to those with mail items over 180 days, I used some VBA functions to extract the user name and the department (the users are placed into OUs by department and the result of the get-mailboxfolderstatistics cmdlet is the full "path" to the users folder including domain and OUs, so it was pretty easy for me to get their department)


3. I then copied the results to a new list and used an advanced filter on this list to get unique records only, and I had the final list of users with items over 180 days.

Scheduling your server to Automatically Reboot

How to schedule your server to automatically reboot itself at a pre-determined time

Windows Server 2003 comes with the built-in ability to schedule your server to reboot at any time of your choosing. It is quite simple to set up.

Navigate to Start -> All Programs -> Accessories -> System Tools -> Scheduled Tasks.

Click on the icon which says Add Scheduled Task.

You should now see the Add Scheduled Task Wizard. Click Next.

Disregard the list of programs, and click the Browse button.

By default, the browse button will bring you to the root of the C: drive. Navigate to WINDOWS -> system32 and locate the file named ‘shutdown.exe’. Highlight it, and click Open.

Enter your desired name for this task. For the purposes of this article, we will name this task ‘Auto-Reboot’. Next, choose how often you would like your server to reboot, whether it is daily, weekly, or monthly. For example, let’s select monthly. Once selected, click Next.

Here, you can select the time and date of the month you would like the server to automatically reboot. For example, we will select 1:00 AM for the time. As you can see, you have many configurable options available for which day of the month you prefer. For example, we will choose the Last Thursday of the month. Once your desired options have been set, click Next.

Type in the password for the user you would like this task to run under. If you are setting this task to run under your ‘ServerAdmin’ login, enter the ‘ServerAdmin’ password. Once entered, click Next.

On the next screen, place a check-mark in the option for 'Open advanced properties for this task when I click Finish'. Once the check-mark is entered, click Finish.

Now, we need to enter a specific command to make the server reboot rather than simply shutdown. Add the following line in the Run field after ‘shutdown.exe’, without the parentheses:

            (-r -t 00)

The Run field should now look like this:

You will need to enter your ‘ServerAdmin’ password to confirm the changes. Once entered, click OK.

You have now set Windows to automatically reboot as the time you have specified.

Connecting to Cluster Local node when cluster resource is down!!!

It's possible that your cluster network name resource may be offline.

Start--> Run, enter either of the following commands, and click ok

cluadmin "node name"

cluadmin .

The cluadmin "nodename" depends on the IP resource, and name resolution, so if either of those aren't working you may have to use the . switch

Putting a space+dot after cluadmin should cause your cluster administrator console to connect directly to the local node, and you can see if the network name resource is offline... if it is, bring it online, and then you should be able to connect cluster administrator to the cluster name again.

Active Directory UserAccountControl

Quick Reference

This table provides a quick reference guide to common userAccountControl values. This is not intended to be a complete reference.

Value	Description
512	Enabled Account
514	Disabled Account
544	Enabled, Password Not Required
546	Disabled, Password Not Required
66048	Enabled, Password Doesn't Expire
66050	Disabled, Password Doesn't Expire
66080	Enabled, Password Doesn't Expire & Not Required
66082	Disabled, Password Doesn't Expire & Not Required
262656	Enabled, Smartcard Required
262658	Disabled, Smartcard Required
262688	Enabled, Smartcard Required, Password Not Required
262690	Disabled, Smartcard Required, Password Not Required
328192	Enabled, Smartcard Required, Password Doesn't Expire
328194	Disabled, Smartcard Required, Password Doesn't Expire
328224	Enabled, Smartcard Required, Password Doesn't Expire & Not Required
328226	Disabled, Smartcard Required, Password Doesn't Expire & Not Required

Microsoft Lync 2013 does not update status based on Outlook Calendar KB2804472

Microsoft Lync 2013 does not update status     based on Outlook Calendar KB2804472

From the beginning, when we installed the Microsoft Lync 2013 client, we had a problem with the fact that Lync 2013 does not update the status on the basis of meetings listed in the Outlook calendar.

The result of this was that we had to adjust the status of Lync 2013 client manually for Busy eg.: when a calendar appointment was entered, and then adjust it to Available, after appointment.

We tried different ways to resolve this problem, and make Lync 2013 to automatically update status: reinstall the Lync 2013 client, removing all data from the directory:

C:\Users\rszatkowski\AppData\Local\Microsoft\Office\15.0\Lync

remove and recreate Lync user account, change Windows OS version to 7 or 8 with the same result.

Unfortunately, nothing helped, so this weekend we decided to finally take the subject seriously.

As it turned out, after a search we found KB2804472 article published by Microsoft on 01/17/2013, which solved the problem.

We’ve read that primary SMTP address assigned to mailbox is causing problems, with status updates in Microsoft Lync 2013.

In this article you can read that:

This problem may occur when the user’s primary SMTP address contains uppercase characters.

It is in our opinion a very strange behavior, because most e-mails rather on Microsoft Exchange servers are created so that the first letters of the name and the names are spelled with a capital letter.

In this case, at the time of implementation of all the Lync 2013 client, suddenly we had a lot of users unhappy with the operation of the new client.

The solution to the problem, and in fact the workaround recommended by Microsoft is, of course, change the SMTP primary address to lowercase letters.

Unfortunately, such operations can not be performed easily in the console EMC because SMTP address rewriting to lowercase letters for the console is not recognized as any change in the EMC console and the address is entered again as it was with capital letters.

You need to change letters to lowercase and in the same time add some sign (letter or digit) to address and save.

Then address will be saved with lowercase letters.

After this operation, we need to re-edit the address and remove the appended character.

We hope that the issue with Microsoft Lync 2013 status will not be swept under the carpet by Microsoft and in the next update or CU for Microsoft Lync will be corrected.

Getting an Exchange Database into a Clean Shutdown State using Eseutil

by MIKE PFEIFFER on APRIL 11, 2010

So you've just restored an Exchange database, and now you are trying to mount it. To your surprise, you are getting an error similar to the following:

Couldn't mount the database that you specified. Specified database: DB2; Errorcode: An Active Manager operation failed. Error: The database action failed. Error: An error occurred while trying to select a database copy for possible activation. Error: The database 'DB2' was not mounted because errors occurred either while validating database copies for possible activation, or while attempting to activate another copy. Detailed error(s):

An Active Manager operation failed. Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-550)

Before you can mount a database restored from a backup, it needs to be in a clean shutdown state. You can use the Eseutil tool to check whether a database is in a clean shutdown state – if it is not in a clean shutdown state you can perform a repair to get the database into consistency.

Soft Recovery using Eseutil

The first thing you want to do is verify that the database is in a dirty shutdown state. We can do this using the eseutil /mhcommand. For example:

The output from the above command shows us that the database is dirty shutdown:

We can also see from the output, under Log Required, the database is missing a transaction log. We can replay log files into the database (as long as they exist) to get the database into consistency. To do this, we use the following syntax with eseutil:

eseutil /r /l /d

For example, my log file prefix is E02, and my database and logs are stored in G:\E_\Program Files\Microsoft\Exchange Server\V14\Mailbox\DAGDB1 . Here is a screen shot of the command:

When this repair is complete, I can run the eseutil /mh command again to verify that the database is in a clean shut down state:

At this point, I'll be able to mount the database. This will almost always work when you restore a database from a Windows Server Backup, but there may be times when this doesn't work and you need to perform a hard repair.

Performing a Hard Repair

Performing a hard repair using eseutil /p will check the database for any damaged pages; if it finds any, it will delete them. Make sure that you can live without any data inside the database before doing a hard repair, because you may lose data. Also, make sure you have twice as much free space as the size of the database before doing a hard repair – this is required for the temporary database that will be created.

To perform a hard repair, use the eseutil /p command, as shown here:

Once this completes, you can use the eseutil /mh command to verify the database is clean shutdown.

Restore a failed Exchange 2003 Server

Introduction

In order to restore a failed Exchange 2003 Server, you can install a “new” one using the /DisasterRecovery switch, but there are several steps to it, and they need to be performed in the correct order. As I haven’t seen an easily digestive article covering this subject, I thought it was about time to write one.

Note
If you’re the type of Exchange Admin who wants all the details, I suggest you start reading some of the splendid disaster recovery guides available at the Microsoft Exchange Server 2003 Technical Documentation Library. There are also some good guides in the Microsoft Exchange Server 2000 Technical Documentation Library where much of the content also applies to Exchange Server 2003, so that’s definitely worth checking out too.

Making a Copy of the Database and Log files

Depending on the seriousness of the hardware crash and the time available for the restore, I highly recommend you try to make a copy of any accessible database and transaction log files from the server (these are good to have in hand should the databases we restore from backup later on fail), but of course this is only possible if the hard disks containing these files are in a useable state.

Note
Before you can bring the Exchange Server to the state it was in just before the disaster occurred, you would need a copy of the most recent log files.

Installing the New Exchange Server

Server Hardware
When you have received a replacement server or replacements for the failed hardware components, it’s important you configure and partition the disks in the new server, so they are identical to the way they were configured in the old one.

Operating System
We can now install the operating system from the Windows 2003 Server media, also remember to install the Windows Components required by Exchange Server 2003 that is ASP.NET, NNTP, SMTP and the World Wide Web Service. After installing the Windows components we’re ready to apply any Windows 2003 Server Service Pack(s) and post-service pack HotFixes that were installed on the old server.

It’s perfectly fine to give the new server the old server’s NetBIOS name and IP address etc. during the installation, but don’t make the server a member of the domain just yet, instead install it into a workgroup. As the Exchange Server 2003 computer account still exists in Active Directory, we need to reset it before we can make the new Server a member of the domain. This is done by logging on to one of your Domain Controllers (or from any other server or workstation that’s got the Windows 2003 Server Adminpak installed) and opening the Active Directory Users and Computers (ADUC) MMC snap-in, here you drill down and select the Computers container where you right-click the Exchange Server object in the right pane and select Reset Account as shown in Figure 1 below.


Figure 1: Resetting the Computer Account in Active Directory

Click Yes as in Figure 2, then click OK.


Figure 2: Accepting Resetting the Computer Account

When the Computer Account has been reset you can add the “new” Exchange Server to the Active Directory domain by right-clicking My Computer and selecting Properties then clicking Computer Name > Change and specify the Active Directory domain as shown in Figure 3.


Figure 3: Adding the new Exchange Server to the AD domain using the same name

Click OK and specify an account with the permissions necessary to add the computer to the domain, then click OK twice and let the computer reboot. When the computer has rebooted you should logon using an account with the permissions required in order to install Exchange.

Installing Exchange Using the Disaster Recovery Switch

Now that Windows 2003 Server has been configured and prepared, we can move on and start installing Exchange Server 2003 using the /DisasterRecovery switch.

Note
The reason why we install Exchange 2003 Server using the /DisasterRecovery switch is because the configuration information for the Exchange Server still lives in Active Directory. Installing Exchange 2003 Server using the /DisasterRecovery switch will add all necessary Exchange binaries to the server, as well as restore the default Exchange registry settings and re-register the necessary DLL files etc. without touching the configuration information still held in Active Directory.

To get going, insert the Exchange Server 2003 media then click Start > Run and type:

:\Setup\I386\Setup.exe /DisasterRecovery

Where drive is the CD-ROM drive or a mapped drive to a share containing the Exchange 2003 Server binaries. See Figure 4 below.


Figure 4: Running Exchange Server 2003 Setup with the Disaster Recovery Switch

Click Next > Accept the License Agreement then click Next one more time. We will now be presented with the Exchange Components screen shown in Figure 5 below.


Figure 5: Exchange Server 2003 Component Selection

It’s important you specify the same Install Path as the Exchange binaries was installed in on the old server, when you have done so click Next. The Exchange Server 2003 Installation Wizard will now install Exchange in Disaster Recovery mode, see Figure 6 below.


Figure 6: Exchange Server 2003 Installation Wizard Running in Disaster Recovery Mode

Just before the Post-installation kicks off you will get the dialog box shown in Figure 7, it reminds you that the Exchange databases need to be restored from backup after the installation of Exchange Server 2003 in Disaster Recovery mode has completed. Click OK and let the installation finish.


Figure 7: Information Box Reminding You to Restore the databases from Backup

Click Finish.


Figure 8: Completing the Microsoft Exchange Wizard

We now have to install any Exchange 2003 Service Packs that had been applied to the old server, and it’s important that the Service Pack is applied using the /DisasterRecovery switch just like the case with the Exchange Server installation. Similar to the installation of Exchange server this is done by clicking Start > Run and typing:

:\E2K3SP1\Setup\Update.exe /DisasterRecovery

Where drive is the CD-ROM drive or drive mapped to the share containing the Exchange Server 2003 Service Pack 1 binaries.

Note
If installing Exchange Server 2003 Service Pack 1 on a Windows 2003 Server without Service Pack 1 applied, you should apply the HotFix mentioned in MS KB article: 831464 - FIX: IIS 6.0 compression corruption causes access violations prior to installing Exchange Server 2003 Service Pack 1.


Figure 9: Applying Exchange Server 2003 Service Pack 1 using the Disaster Recovery Switch

Click OK then Next. Accept the Agreement and click Next. Verify the Install Path (Figure 10) then click Next.


Figure 10: Exchange Server 2003 Service Pack 1 Component Selection

Note
We will again be reminded that we have to restore the databases from backup after the Installation Wizard finishes off.

Click OK and Finish when the installation has completed, but don’t reboot the server just yet.

Restoring the Exchange Databases

We can now begin restoring the Mailbox and Public Folder Stores from backup, in this article we use NT Backup, you should of course use the backup solution implemented in your Exchange messaging environment.

Before we do anything else let’s open the Exchange System Manager and drill down and expand the Mailbox and Public Folder Stores. Because we installed Exchange Server 2003 using the /DisasterRecovery switch, they should be in a dismounted state, which is also the case in Figure 11 below.


Figure 11: Dismounted Stores in the Exchange System Manager

Note
If you managed to take a copy of the Exchange databases and log files from the old server, now is the time to bring them back to their respective location(s) on the new server and have them mounted. Depending on the state of the stores, you may have to repair them before they can be mounted.

Now start NT Backup by clicking Start > Run and type NTBackup then click the Restore and Manage Media tab. In order to restore the databases from backup right-click File in the left pane and select Catalog, then click Browse and locate the .BKF file or media containing the data that is to be restored. When it has been opened expand the Catalog then select the respective Mailbox and Public folder stores as shown in Figure 12.


Figure 12: Selecting the Mailbox and Public Folder Stores that are to be Restored

Click Start Restore. The box shown in Figure 13 will appear, here the server should already be specified in the Restore To: field, if not do so now. In the Temporary location for log and patch files: specify a temp folder such as the one in Figure 13. Make sure to enable the Last Restore Set (Log file reply will start after this restore completes.) checkbox if there are no additional log files to restore. Select the Mount Database After Restore checkbox depending on whether you want the stores to mount automatically after the restore.

Note
There’s one important thing to have in mind when restoring one or more Mailbox Store(s) from backup after installing a new Exchange Server using the /DisasterRecovery switch, and that is if an Exchange Recovery Storage Group exists when doing the restore, all stores will be redirected to the Recovery Storage Group. This will make the restore job fail and an Event ID Error 9635 will be thrown to the Application log. In order to resolve this problem delete the Recovery Storage Group prior to doing the restore. If you for some reason don’t want to delete the Recovery Storage Group, you can add a DWORD value named Recovery SG Override under HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem. Make sure you enable it by specifying 1 in the Value Data box.

Click OK and let the restore job complete.


Figure 13: Specifying the Server and Temp location of the Log files

Click Close.


Figure 14: The Restore is Complete

Now open the Exchange System Manager one more time and verify all Mailbox and Public Folder Stores have been mounted, if not mount them manually. When all the Stores have been mounted make sure you can see the mailboxes in the Mailboxes container under each Mailbox Store. Also verify all Public Folders are listed under in the Public Folder tree. If things show up as expected try to logon to a Mailbox and verify Mail flow, if successful we can call the restore a success – congratulations

About Henrik Walther

Henrik Walther is a Microsoft Exchange MVP, MCA: Messaging (Exchange Ranger) Apprentice, MCITP: Exchange 2007, MCTS: Windows 2008, and MCSE: M+S that works as a Technology Architect for Timengo Consulting A/S, a Microsoft Gold Partner based in Denmark. You can visit his website at: www.exchange-faq.dk (danish).

Click here for Henrik Walther's section.