This is much easier in Exchange 2007 than it was in Exchange 2003 as here we can use PowerShell. I would like to mention that in case of using Ex 2007, we don’t even have to create the users in advance, the server will take care of that for you. For the full 2007 PowerShell reference guide please see this page http://technet.microsoft.com/en-us/library/bb123703%28EXCHG.80%29.aspx#NthruR

In short, in order to create a new user type in:

New-Mailbox -Name <String> -Database <DatabaseIdParameter> -Password <SecureString> -UserPrincipalName <String> [-DisplayName <String>] [-FirstName <String>] [-Initials <String>] [-LastName <String>]

You might notice that if you simply type a string in for the password you’ll get an error:

New-Mailbox : Cannot bind parameter 'Password'. Cannot convert value "[given_password]" to type "System.Security.SecureString". Error: "Invalid cast from 'System.String' to ‘System.Security.SecureString'."

The reason for this is that the given password has to be a secure string type. In order to create it, type in the following (has to be separate from the previous command):


$Password = ConvertTo-SecureString '<string>' -AsPlainText –Force

After this you could refer to the given password as $Password.

We usually use this command in two different ways. The first one is to use a scripting language (my preference is Python) to generate the commands with different names. I have a list with the thousand most popular first names and the thousand most popular surnames. My script simply combines the two, giving me quite a lot of options. The second method is to name the users using a counter such as User 1; User 2;… User n and use a cycle in PowerShell to generate all required user names, such as:

$Password = ConvertTo-SecureString '<password>' -AsPlainText –Force

for ($i=0; $i -le 10; $i++)

{

New-Mailbox –Name <name>$i -Database <dbname> -Password $Password -UserPrincipalName <UPname> -DisplayName "<name> $i" -FirstName <firstname> -LastName $i

}

If someone doesn’t like PowerShell or doesn’t have it (e.g. Exchange 2003), the batch files I mentioned earlier used in active directory work just fine. After creating the users using those the mailboxes can be assigned to them fairly easily. In Exchange 2007, we have to start the “create new mailbox” process and select “existing users” in the first window.

This will show all users in AD that don’t have mailboxes. Fortunately multiselection is allowed so we don’t have to handle them one by one. Exchange 2003 doesn’t have this feature but there’s an easy workaround. Do a search using Exchange 2003’s Active Directory Users and Computers application for all users and multiselect them. Right clicking once will open the context menu where we can select “Exchange tasks” and “Create exchange mailbox” from there.

Finally, the command to add full access rights to a specific user so all mailboxes could be opened (and managed) from one outlook:

foreach ($sg in Get-StorageGroup) { if ((Get-ExchangeServer
$sg.Server).Domain.Equals("DomainName.com")) { get-mailboxdatabase
-storagegroup $sg.Identity | add-adpermission -user UserName
-accessrights GenericAll; } }

Retention policies are the recommended method for implementing messaging records management in Exchange 2010. Retention policies use retention tags to apply settings to mailbox folders and individual items. Retention tags are configured with a retention action that can be taken when an item reaches its retention age limit.

Retention Cmdlets

There is currently no way to manage retention tags or policies through the Exchange Management Console (EMC). Retention tags and policies must be managed using the Exchange Management Shell (EMS).

When managing retention settings in EMS, you’ll use the following cmdlets:

• Retention Policy Cmdlets – Get-RetentionPolicy, Set-RetentionPolicy, New-RetentionPolicy and Remove-RetentionPolicy
• Retention Policy Tag Cmdlets – Get-RetentionPolicyTag, Set-RetentionPolicyTag, New-RetentionPolicyTag, and Remove-RetentionPolicyTag

Retention Tag Types

There are three types of retention tags that can be used to apply retention settings to mailbox folders and messages:

• Retention Policy Tags – these tags are used to apply settings to default folders such as Inbox and Sent Items.
• Default Policy Tags – these tags apply to any item that does not have a retention tag set. A retention policy can contain only one default policy tag.
• Personal Tags – these tags can be applied by users who access their mailboxes from Outlook 2010 or Outlook Web App. Personal tags can be applied to custom folders and individual items.

Retention Actions

When you create a retention tag, you can select a retention action that will be used when the age limit for retention is met. The following table lists the available retention actions:

• DeleteAndAllowRecovery – This action will perform a hard delete, sending the message to the dumpster. The user will be able to recover the item using the Recover Deleted Items dialog box in Outlook 2010 or Outlook Web App.
• MarkAsPastRetentionLimit – This action will mark an item as past the retention limit, displaying the message using strikethrough text in Outlook 2007, 2010 or Outlook Web App.
• MoveToArchive – This action moves the message to the users archive mailbox.
• MoveToDeletedItems – This action will move the message to the Deleted Items folder.
• PermanentlyDelete – This action will permanently delete the message and cannot be restored using the Recover Deleted Items dialog box.

Creating Retention Tags

When you create a retention policy tag using the New-RetentionPolicyTag cmdlet, you can specify the default folder type using the Type parameter.

The following default folders can be used when creating retention policy tags:

• Deleted Items
• Drafts
• Inbox
• Junk E-mail
• Outbox
• Sent Items
• RSS Feeds
• Sync Issues
• Conversation History

Using the information we’ve learned so far, let’s take a look at a few sample commands. The following command will create a retention policy tag for the default Inbox folder, specifying that items older than 90 days will be deleted permanently:

New-RetentionPolicyTag AllUsers-Inbox -Type Inbox -Comment `
"Items older than 90 days are deleted" -RetentionEnabled $true `
-AgeLimitForRetention 90 -RetentionAction PermanentlyDelete

To create a default policy tag for the entire mailbox, set the type to All. In this example, a default retention policy tag is created that will permanently delete items after 120 days. A default retention policy tag of type All will apply to any item that does not have a retention tag applied:

New-RetentionPolicyTag AllUsers-Default -Type All -Comment `
"Items older than 120 days are permanently deleted" -RetentionEnabled $true `
-AgeLimitForRetention 120 -RetentionAction PermanentlyDelete -IsPrimary $true

When creating a personal retention tag, use Personal for the Type parameter value. The following command will create a tag that can be used for critical personal items, retaining items for two years before being deleted:

New-RetentionPolicyTag Critical -Type Personal -Comment `
"Use this tag for all critical items" -RetentionEnabled $true `
-AgeLimitForRetention 730 -RetentionAction DeleteAndAllowRecovery

Creating Retention Policies

You use retention polices to apply retention tags to mailboxes. When creating retention polices, keep the following in mind:

• Mailboxes can only be assigned one retention policy at a time.
• You cannot have multiple retention policy tags for a single default folder in the same retention policy. For example, you can’t have two retention policy tags for the Inbox default folder in the same retention policy.
• Policies can contain one default policy tag of type All.
• You can assign multiple personal tags to a policy, but be careful not to go overboard as this could be confusing for users.
• Retention tags are not applied to mailboxes until they have been linked to an enabled retention policy and the managed folder assistant has run.

To create a retention policy, use the New-RetentionPolicy cmdlet. The following example creates a retention policy named All-Users that links the AllUsers-Inbox tag to the policy:

New-RetentionPolicy AllUsers -RetentionPolicyTagLinks AllUsers-Inbox

You can create a retention policy without initially linking any retention tags to it. You can always go back and add retention tags to a policy later. If you need to add tags to an existing policy, you can use the Set-RetentionPolicy cmdlet. For example, to add the Sales-Inbox and Sales-DeletedItems retention policy tag to the Sales-Users retention policy, your command would look like this:

Set-RetentionPolicy -Identity Sales-Users -RetentionPolicyTagLinks Sales-Inbox

When updating a retention policy that already has tags linked, you need to re-apply those tags and append any new tags you will be linking. In this case, you could use the following syntax to update the Sales-Users retention policy:

#store the current tag list
$Tags = (Get-RetentionPolicy Sales-Users).RetentionPolicyTagLinks
#create a list of new tags
$NewTags = Get-RetentionPolicyTag Sales-Critical
#store all tags in a new varable
$Tags += $NewTags
#add all tags to the retention policy
Set-RetentionPolicy Sales-Users -RetentionPolicyTagLinks $Tags

Applying Retention Policies to Mailboxes

To apply a retention policy to a mailbox, you use the Set-Mailbox cmdlet, specifying the retention policy name using the RetentionPolicy parameter. Below are a few examples.

Setting the RP-IT retention policy for a single user:

Set-Mailbox dsmith -RetentionPolicy RP-IT

Setting the RP-Sales retention policy to all mailboxes in the sales distribution group:

Get-DistributionGroupMember DG-Sales | Set-Mailbox -RetentionPolicy RP-Sales

Setting the RP-AllUsers retention policy to all mailboxes in the DAGDB1 database:

Get-Mailbox -Database DAGDB1 | Set-Mailbox -RetentionPolicy RP-AllUsers

These commands will only apply to the mailboxes currently in the distribution group or mailbox database. You’ll need to schedule these commands to run on a regular basis if you are making changes to the group or database frequently.

Auto Tagging

You can enable auto tagging to automatically tag items in a user’s mailbox based on their past tagging activities. To enable auto tagging for a mailbox, use the Set-MailboxComplianceConfiguration cmdlet and set the RetentionAutoTaggingEnabled parameter to $true as shown below:

Set-MailboxComplianceConfiguration dsmith -RetentionAutoTaggingEnabled $true

Keep in mind that the user needs to first tag a minimum of 500 items so that Exchange can learn the tagging habits of that user.

You can see how many messages a user has tagged by running the Get-MailboxComplianceConfiguration cmdlet:

Get-MailboxComplianceConfiguration dsmith

To clear auto tags from a mailbox use the same cmdlet using the Clear switch parameter:

Start-RetentionAutoTagLearning –Identity djones -Clear

You can start the training algorithm for auto tagging using the Start-RetentionAutoTagLearning cmdlet:

Start-RetentionAutoTagLearning –Identity djones -Train

Default Retention Policies

Exchange automatically creates retention policies for use with personal archives and arbitration mailboxes. There are two retention policies created automatically by default:

• Default Archive Policy – this policy can be applied to mailboxes that contain a personal archive and provides a built in set of retention tags.
• ArbitrationMailbox – this policy is applied by default to the system mailbox. The policy contains two system tags by default.

The retention tags used within these policies are considered system tags, and by default are not visible when running the Get-RetentionPolicyTag cmdlet. You can view the tags included with these policies by using the IncludeSystemTags parameter with the Get-RetentionPolicyTag cmdlet. For example, to view a list of retention policy tag names, including the system tag names, run the following command:

Get-RetentionPolicyTag –IncludeSystemTags | select name

Retention Hold

You may need to disable the processing of a retention policy for a user that will be out on vacation or on a leave of absence. In this instance, you can use the RetentionHold parameter of the Set-Mailbox cmdlet to suspend the processing of a retention policy.

Set-Mailbox dsmith -RetentionHoldEnabled $true

Managed Folder Assistant

The Managed Folder Assistant runs on each mailbox server, applying message retention settings configured in retention polices or managed folders. By default, the Managed Folder Assistant is scheduled to run from 1am to 9am every day.

You might find that you need to run the Managed Folder Assistant manually in order to test the functionality of your tags and policies. In this case, you can use the Start-ManagedFolderAssistant cmdlet to force the Managed Folder Assistant to run immediately.

To start the Managed Folder Assistant for a particular mailbox:

Start-ManagedFolderAssistant –Mailbox dsmith

To start the Manged Folder Assistant on a particular server:

Start-ManagedFolderAssistant –Identity EXCHSRV01

This can be a resource intensive task when running against all of the mailboxes on a server. Make sure that your systems can handle the additional work, or do your testing after business hours.

That covers all of the concepts you need to know to manage retention policies. I know this may seem like a lot of information, but do some testing in a lab environment. Create some retention tags and policies and practice assigning them to users and I think you will see that they are actually pretty easy to work with.

Working on Exchange email archiving software and PST Importing tools we have a test network with quite a few virtual machines, many with Windows Server 2008 installed.

The first lesson learnt was to never try to create a virtual (or real) Windows 2008 network with less than 50 GB of hard drive space. The Windows installation itself takes up about 10 GB, and then everyone’s favourite the winsxs folder will just grow and grow,  and in the end you run out of disk space although you have nothing else on your C drive but a basic server installation and Exchange (Exchange installation that is, all relevant data files and databases are on a different drive of course).

Anyhow, after a while we found ourselves in a situation where we have a nice pool of complex networks with virtual machines and half of them are complaining about low disk space. The solution is to extend the virtual disk, but it’s not as easy as one might think.

First, you have to shut your virtual machine down, open a command prompt on your host and navigate to your VMware server installation where you’ll have to use vmware-vdiskmanager.exe as such:

vmware-vdiskmanager.exe –x [Size][dimension] [path to virtual disk]

e.g.: vmware-vdiskmanager.exe –x 50Gb E:\virtual_machines\Medium\Exchange4\Exchange4.vmdk

Make sure that you specify the real virtual disk’s path and not the flat file or a partial slice (the tool’s error reporting is very poor on that regard). You also have to make sure that you have no snapshots for the computer in question otherwise the tool will refuse to work (with the proper error message this time at least).

If everything goes well, your virtual disk will be resized to the specified value after the process finished. The next step is to mount this drive into a different virtual machine, and edit its partitions using Disk Manager (built-in UI) or diskpart which is a built-in command line tool. If you choose the former, you’ll have to select the drive that you wish to make bigger, right click on it and select “extend”, while in diskpart type:

list volume
select volume [n]
extend

List volume lists all available volumes, with the select command you can select the one that is to be extended and type extend to carry out the action.

After all this, theoretically just unmount (remove) your disk from the second machine, start the first one up and it should all work fine.

It worked for Windows Vista, but my Windows 2008 failed to boot with the error:

Can’t find c:\Windows\System32\winload.exe the file is missing or corrupted

This seemed vaguely familiar, I thought it’s just the old “NTLDR is missing or corrupted” that I was always able to fix using the installation disk. I was looking forward to have some built-in tool in the installer that might just have been developed to fix such issues. To my surprise, there was none.

The repair options were “Restore computer”, “Windows Memory Diagnostic Tool” and “Command Prompt”. Unfortunately Restore Computer needs a backup file to work with that I obviously didn’t have (virtual test machine) and rebuilding it wasn’t an option as it was one of my exchange servers in the system… I started to get rather upset and stressed about it and began googling for the problem desperately.

The first few hits were of no help and at some point I even wandered around Microsoft’s TechNet forum where I read that the start-up repair option was removed from 2008 per design (!?). It wasn’t easy, but after several unsuccessful searchers I found another blog post with the solution:

Execute next commands in repair mode (Vista / Win2k8):
c:\windows\system32\bcdedit /set {default} device partition=c:
c:\windows\system32\bcdedit /set {default} osdevice partition=c:
c:\windows\system32\bcdedit /set {bootmgr} device partition=c:

It worked like a charm, my system could boot without any problems and I didn’t have to waste a day to reinstall the server and exchange.

The first step was the easiest – create around a hundred machines in different organisational units in active directory.

We needed this part as our Search wizard queries Active Directory for computers in the system. The user than can select the computers they wish to search for PST files. The grid where they are displayed and various features around selection should be tested, but at this stage it is enough if the computer is simply created in Active Directory. You can go to your Domain Controller, run “Active Directory Users and Computers” management console, right click on any container, select “New” and select “Computer”. This way you can create any computer in your AD tree without physically having it in your system. If one desires to create a larger amount of computers, doing it manually really shouldn’t be an option, in which case a simple .bat file solves the problem.

To create an OU where the new computer(s) should go:

dsadd ou "OU=[name_of_OU],DC=[name_of_domain],DC=[name_of_domain]"

For embedded OUs:

dsadd ou “OU=[name_of_OU_child2], OU=[name_of_OU_child1], OU=[name_of_OU_parent],DC=[name_of_domain],DC=[name_of_domain]”

To add the computer:

dsadd computer "cn=[computer_name],ou=[ou_name(s)],dc=[name_of_domain],dc=[name_of_domain]" -uc

And now that we have the window open anyway, to add a user:

dsadd user "CN=[user_name],OU=[name_of_ou],DC=[name_of_domain],DC=[name_of_domain]" -samid [name_of_user (SAM id)] -upn [user_name@fqdn]
-fn [First_name] -ln [last_name] -display "[display_name]" -pwd [password]

This enables us to test most of the basic grid functionality and enablement. In order to check that these non-existing machines are handled correctly when the PST agent is installed on them our developers created a “data faker”, that browses the AD tree to get all computer names and we can set all available statuses for the computers found. This data faker is used to simulate search results as well.

We usually do a script that creates these user/computer names with an incrementing counter, but in some cases it might be a collection of really nasty characters/deeply embedded OUs or other special cases.

*Coming up in Part 2 – Reka will cover scripts to create mailboxes in Exchange 2007, and how to modify access rights on them.