In Exchange Server 2007 this is not too difficult to accomplish. Microsoft has released a whitepaper on how to configure virtual organizations (i.e. companies) in Exchange Server 2007. This whitepaper can be found on the Technet Website: http://technet.microsoft.com/en-us/library/bb936719(EXCHG.80).aspx – Configuring Virtual Organizations and Address List Segregation in Exchange 2007.

It is tempting to try this in Exchange Server 2010 as well, but you would be best off avoiding doing so. There are a couple of issues (that Microsoft is working on) that will block a successful rollout of Address List Segregation. Besides that, it is not supported and it will also break Exchange Server 2010. More information regarding this can be found on Dave Goldman’s weblog: http://blogs.msdn.com/b/dgoldman/archive/2010/05/10/critical-update-exchange-2010-address-list-segregation-and-current-support-stances.aspx – CRITICAL UPDATE – Exchange 2010 Address List Segregation and Current Support Stances

You may be aware that in Exchange Server 2010 SP1 there’s a /hosting switch, making Exchange Server 2010 SP1 “multi tenant”. This means you can create multiple virtual organizations in Exchange Server 2010 SP1, completely invisible for each other. There’s already quite some information on the Internet regarding installation of Exchange Server 2010 SP1 with the /hosting switch, but most of this information is not coming directly from Microsoft!

This “hoster edition” of Exchange Server 2010 SP1 is targeted towards hosting companies, companies that currently have HMC (Hosted Messaging and Collaboration) 4.5 running. This is basically the Hosted Version of Exchange Server 2007, including Hosted Sharepoint and Hosted OCS. This implementation of Exchange Server 2010 is absolutely not targeted towards enterprise customers!

There are a number of issues you have to be aware of when you want to deploy the “hoster edition” of Exchange Server 2010 SP1:

• You need an SPLA (Service Provider License Agreement) to use this version of Exchange Server 2010 SP1;
• The Forest Functional level is Windows Server 2008;

There is:

• No upgrade path (only a green field scneario);
• No support for Unified Messaging;
• No support for Edge and EdgeSync;
• No support for multiple forests;
• No support for multiple domains;
• No Exchange Management Console;
• No Public Folders;
• No Federation;
• No B2B features such as cross-premises message tracking and calender sharing;
• No IRM;
• No Outlook 2003 support (EnableLegacyOutlook);
• No Support for OCS 2007 R2, only from 3rd party;
• No Support for CRM;

When you try to start the Exchange Management Console you’ll see that it is not supported:

So, all configuration has to be done using the Exchange Management Shell. There’s some additional self service support on the Exchange Control Panel, but basically you’ll need to implement another 3^rd party Control Panel for configuring the Exchange organization. Or create your own Control Panel. Please bare in mind that hosting companies often have dedicated developers that are working on these scenarios.

Conclusion

If you want to implement Address List Segregation on Exchange Server 2010 you cannot use the 2007 version of the Address List Segregation whitepaper. It will break Exchange Server 2010. Although very tempting to use, the Hoster Edition of Exchange Server 2010 SP1 is not an alternative for the enterprise customers. Don’t try it, don’t even think about it, there’s too much complexity for the average enterprise customer. Besides the Service Provider licensing, there’s too much functionality that’s not supported by Microsoft directly, or it is supported by a 3^rd party. The best option is to wait and see if and when Microsoft releases the 2010 version of the Address List Segregation.

How is this possible?  Could it be that single instance storage never really had real benefits?  Or maybe because it had been weakened in 2007 (so that only attachments within a storage group were single-instanced), we already paid the tax?

Well, the mystery has been solved:  in Exchange 2010, MS introduced compression.  In more detail,

“As a result of the new architecture and the other changes to the store and ESE, we had to deal with an unintended side effect.  While these changes greatly improved our IO efficiency, they made our space efficiency worse.  In fact, on average they increased the size of the Exchange database by about 20% over Exchange 2007. To overcome this bloating effect, we implemented a targeted compression mechanism (using either 7-bit or XPRESS, which is the Microsoft implementation of the LZ77 algorithm) that specifically compresses message headers and bodies that are either text or HTML-based (attachments are not compressed as typically they exist in their most compressed state already).  The result of this work is that we see database sizes on par with Exchange 2007.”

http://msexchangeteam.com/archive/2010/02/22/454051.aspx

So!  It seems that Microsoft has not been as off-hand with our storage as it seemed.  The message from Redmond has mostly been, ‘Ah, storage is cheap – and even cheaper for Exchange 2010 – so losing SIS isn’t a big deal.’

But, heart-warmingly, they were looking out for our storage needs all along.… which makes me wonder, why the shyness about the compression?  Yes, there will be a performance tax, but most Exchange servers are not performance-limited by the processor.

Is there some other disadvantage to compressing messages in the Exchange database?  I can’t think of one.

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; } }

How is this possible? Could it be that single instance storage never really had real benefits? Or maybe because it had been weakened in 2007 (so that only attachments within a storage group were single-instanced), we already paid the tax?

Well, the mystery has been solved: in Exchange 2010, MS introduced compression. In more detail,

“As a result of the new architecture and the other changes to the store and ESE, we had to deal with an unintended side effect. While these changes greatly improved our IO efficiency, they made our space efficiency worse. In fact, on average they increased the size of the Exchange database by about 20% over Exchange 2007. To overcome this bloating effect, we implemented a targeted compression mechanism (using either 7-bit or XPRESS, which is the Microsoft implementation of the LZ77 algorithm) that specifically compresses message headers and bodies that are either text or HTML-based (attachments are not compressed as typically they exist in their most compressed state already). The result of this work is that we see database sizes on par with Exchange 2007.”

http://msexchangeteam.com/archive/2010/02/22/454051.aspx

So! It seems that Microsoft has not been as off-hand with our storage as it seemed. The message from Redmond has mostly been, ‘Ah, storage is cheap – and even cheaper for Exchange 2010 – so losing SIS isn’t a big deal.’

But, heart-warmingly, they were looking out for our storage needs all along.… which makes me wonder, why the shyness about the compression? Yes, there will be a performance tax, but most Exchange servers are not performance-limited by the processor.

Is there some other disadvantage to compressing messages in the Exchange database? I can’t think of one.

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.

Certificate Types

Before we take a look at some of the more common problems with Exchange certificates, it will help to understand the types of certificates that are used in Exchange:

• Self-Signed Certificates – Exchange installs a default self-signed certificate intended for temporary use. This will provide basic functionality to get you up and running, but as a best practice, it is recommended that you replace these certificates using internal PKI or third-party trusted certificates. Keep in mind that Outlook Anywhere is not supported with a self-signed certificate.
• Windows PKI Certificates – Some organizations choose to implement their own internal PKI and issue certificates to Exchange servers using an internal Certificate Authority (CA). This saves money, but can add administrative overhead, as CA root certificates may need to be manually installed on certain devices.
• Trusted Third-Party Certificates – Commercial certificates, also referred to as Unified Communications Certificates (UCC) are commonly used since they are trusted by default on all computers, which greatly simplifies deployment.

A Quick Note on Autodiscover

Autodiscover provides clients with URLs for the Availability Service (free/busy information, Out of Office), the Offline Address Book and Unified Messaging. Most of the certificate problems I see are related to Autodiscover and these associated services – to fully understand these issues, a quick overview of how Autodiscover works internally might be helpful.

When you install a CAS Server, a Service Connection Point (SCP) record is created in Active Directory – this happens for every CAS server you install. The SCP record contains the FQDN of the associated CAS server. These SCP records are used by Outlook on internal, domain joined machines to discover CAS servers. When a user launches Outlook 2007/2010, it will query Active Directory for these SCP records and return the address of a CAS server. Once the user is connected, Outlook will receive the URLs for the Availability Service (free/busy information, Out of Office), the Offline Address Book and Unified Messaging, all of which need valid certificates.

Common Problems

Here are some of the most common certificate related problems that I see on a regular basis:

1. Unable to resolve fully qualified domain names (FQDN)
Make sure that all FQDNs being used on your certificates have the appropriate A records created in both your internal and external DNS zones.

2. The certificate name does not match the URL
You need to make sure that all FQDNs that will be used to access Exchange services are on the certificate. You can accomplish this using multiple Subject Alternative Names (SANs) when you generate your certificate request using the New-ExchangeCertificate cmdlet.

3. The certificate is not trusted
By default, self-signed certificates are not trusted. Depending on the service you are accessing, and where you are accessing it from, you may receive certificate warnings, or things may not work at all. The best way to get around this is to use a trusted certificate. As mentioned previously, it’s recommended that you replace the default self-signed certificates.

You may run into the same issue using an internal PKI certificate. Depending on the device, you may need to install the root certificate from the issuing CA in the clients local Trusted Root Certificate Authorities store.

4. Autodiscover SCP record is not configured correctly
Depending on your configuration, you may need to update the Autodiscover SCP record. To update the SCP record, use the Set-ClientAccessServer cmdlet, specifying the correct URL using the AutodiscoverServiceInternalUri parameter, for example:

Set-ClientAccessServer -Identity CAS_Server_Name `
-AutodiscoverServiceInternalUri https://autodiscover.domain.com/autodiscover/autodiscover.xml

5. Internal/External URLs are not configured correctly
As I mentioned, Autodiscover will provide client machines with the URLs for Exchange Web Services (free/busy, OOF, etc.), Offline Address Book, and Unified Messaging. You can configure the URLs for these services using the following cmdlets, all of which support the InternalURL and ExternalURL parameters. The commands below are only provided to give you an idea of the syntax. Keep in mind, the FQDNs used for these commands depend on your environment and DNS namespace configuration:

Set-WebServicesVirtualDirectory -Identity “CAS_Server_Name\EWS (Default Web Site)” `
-InternalUrl https://mail.domain.com/ews/exchange.asmx -ExternallUrl https://mail.domain.com/ews/exchange.asmx

Set-OABVirtualDirectory -Identity “CAS_Server_Name\oab (Default Web Site)” `
-InternalUrl https://mail.domain.com/oab -ExternallUrl https://mail.domain.com/oab

Set-UMVirtualDirectory -Identity "CAS_Server_Name\UnifiedMessaging `
(Default Web Site)" -InternalUrl https://mail.domain.com/unifiedmessaging/service.asmx `
-ExternallUrl https://mail.domain.com/unifiedmessaging/service.asmx

6. CAS Array / Load Balanced CAS Servers
I often see customers deploy load balanced CAS Servers without modifying the SCP record, or any other internal URLs. This effectively eliminates these services from being load balanced, as clients will be connecting directly to the CAS servers by name. Also, if the NetBIOS names of the CAS servers are not on the certificate, users will receive a security warning message when connecting to their mailbox that says “The name of the security certificate is invalid or does not match the name of the site”. Use #4 and #5 to correct this issue.

7. Trouble exporting and importing certificates
If you are planning on exporting certificates from one server and importing them on the other, make sure that you set the private key as exportable when you generate your certificate request. For example:

New-ExchangeCertificate -GenerateRequest -SubjectName “c=US, o=Litware, `
cn=mail.litware.internal” -DomainName owa.litware.internal,mail.litware.internal `
-PrivateKeyExportable $true

8. The certificate is expired
I run into this a lot with servers that are using the default self-signed certificate. Use the New-ExchangeCertificate cmdlet if you need to replace an expired certificate or generate a new request. To check the expiration date, use the Get-ExchangeCertificate cmdlet, for example:

Get-ExchangeCertificate | fl notafter

As you can see, there are many details when it comes to working with Exchange certificates. The settings can vary greatly depending on the configuration of your environment, so make sure to plan accordingly.

Let’s start with the tools you need:

• Outlook installed on a client
• ExFolders need to be installed on the Exchange 2010 server
• PFDavAdmin installed on the client

First step will be to export the current Public Folder content using Outlook which is installed on the client. Keep in mind that this will need to be done using an account which has at least read permissions on the folders you would like to export.

To export the Public Folder perform the following steps:

• Select the root of the Public Folder
• Select the file menu
• Select the option import/export
• Choose the option to export to another program
• Define a location where you would like to save the PST file

Depending on how much data is located in your Public Folder infrastructure it can take up to a few hours or even days to export the data. Once exported you may want to copy the PST file to a location which can be accessed by a client in the new forest.

But what about the permissions since the PST will only contain the data. Well in previous versions you could just simple export them using PFDavAdmin and import it again using the same tool. Since Exchange 2010 you will need to import the permissions using ExFolders which is a replacement tool for the PFDavAdmin, you may think why ? Well the answer is quite simple, PFDavAdmin was using WebDav to export the permissions. Since Exchange 2010 doesn’t contain WebDav anymore Microsoft needed to create another tool which can does the same but doesn’t use WebDav.  The good news is that the files which are created by PFDavAdmin can be used by the ExFolders utility.

So we start with using PFDavAdmin, once opened select File and then Connect. A new window will be opened where you will need to specify the Exchange Server and the Domain Controller which is also a Global Catalog server.
Ensure that you have selected the option to connect to the Public Folder and press OK once done.

When the connection is made successful an overview of all the Public Folders will be displayed. In the upper part of the Window a menu bar is displayed, select the Tools option followed by Options. Enable the enable logging to file option. Once that is set select the Tools option followed by the Export Permissions. You will get some options before the export is made, ensure that you have chosen the option all public folders in the scope part and the account name option in the format part. Press OK when all settings are correct and select a location and filename where you wish to save the file.

So now we got both the data and permissions exported so we can start to import them in our new environment.

Before starting the import check the size of the PST file. Default the ProhibitPostQuota is set to 2 GB which will cause an error if you try to import more data. The ProhibitPostQuota can be adjusted by using the set-publicfolderdatabase cmdlet:

Get-PublicFolderDatabase | Set-PublicFolderDatabase –ProhibitPostQuota 3 GB
The command above will first retrieve the Public Folder database identity and then set the ProhibitPostQuota to 3 GB instead of the default 2 GB.

Next step is to start Outlook so we can import the PST file into the Public Folder. Before this make sure you have selected the Public Folder and got the correct permissions to create folders and place content in them.

Select the import/export option in the file menu and the same wizard as we used for exporting will be launched. Select the option to import from another program and select the PST file.

Make sure you select the correct location to import the data in and then press next to start the importing. Depending on the amount of data this can take some time so don’t do this if you are in a hurry.

When the import is finished it’s time to correct the permissions using ExFolder. Just start the program and connect to the Exchange server. After the connection is made select the Tools menu followed by Options. A new window will open where you will have to enable the enable logging to file option, this is a requirement before you can run the import option. After logging is enabled select the Tools menu again and choose the option Import. Select the file created with PFDavAdmin to set the correct permissions on the imported folders.

1. Find out how big (or hopefuly small!) our own PST problem is, and
2. Test our new PST Importer tool

To accomplish both objectives we used Microsoft System Center Configuration Manager 2007 R2 to deploy the PST Importer Agent to all corporate desktops.This is how we did it! With the System Center Configuration Manager infrastructure (SCCM) in place, the default collection “All Windows Workstation or Professional Systems” was selected to push the PST agent to PCs running the SCCM client agent.

The PST Agent 32 & 64 bit .MSI installer,  were added to the system center software distribution packages for silent deployment to Windows 7 x64 and Windows XP x86.

A previous deployment of the ESA outlook plugin, included the Microsoft .NET Framework Version 2.0.  Therefore the client PC ‘s met the PST agent prerequisite.

Create the PST Importer Agent package manually

1. In the Configuration Manager console, navigate to System Center Configuration Manager / Site Database / Computer Management / Software Distribution.
2. Right-click Packages, point to New, and then click Package.
3. Use the New Package Wizard to create a software distribution package, specifying general information, data source, distribution settings, and other information for the new package.

Create the PST Importer agent package manually

4. Use the Data Source page in the Configuration Manager 2007 New Package Wizard to specify the file location of the PST Agent. msi

Create the PST importer Agent package manually

5. Complete the wizard with your preferred options

Create the PST Importer Agent Install Program manually

1. In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / Computer Management / Software Distribution / Package / Red-Gate Software PST Importer Agent
2. Right-click Programs, point to New, and then click Program.
3. Use the New Program Wizard to create a program for a software distribution package:

-For the Silent 32bit install program we use the command line:

msiexec /i “PST Agent_1.0.0.852_x86_r103425.msi” /qn /norestart CENTRALSERVICEHOST=myESAserver.mydomain.com  (myESAserver.mydomain.com being where the pst importer tool is installed).

-For alternative installer options , please refer to: Command-Line Switches for the Microsoft Windows Installer Tool  http://support.microsoft.com/kb/227091

Create the PST Importer Agent Install Program manually

4. Then create a new program for the x64 for version (repating the steps above)

Create the PST importer Agent Uninstall Program manually

1. Repeat the above program install steps, using the msiexec /uninstall command line:

msiexec /uninstall ” PST Agent_1.0.0.852_x64_r103425.msi” /qn /norestart CENTRALSERVICEHOST=myESAserver.mydomain.com

Create the PST Importer Agent Uninstall Program manually

Create the PST Importer Agent package from a Package Definition File

Alternately you can create the PST importer Agent package and programs from a Package Definition File.

1. In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / Computer Management / Software Distribution.
2. Right-click Packages, point to New, and then click Package from Definition.
3. Use the Create Package from Definition Wizard to create a software distribution package based on an existing package definition file.
4. Use the Package Definition page in the Configuration Manager 2007 Create Package from Definition Wizard, to select the PST Agent_1.0.0.852_x86_ r103425.msi

Create the PST Importer Agent package from a Package Definition File

5. Then edit command lines to suit your requirements

Command-Line Switches for the Microsoft Windows Installer Tool  http://support.microsoft.com/kb/227091

Select the Client operating Systems the agent should run on

Use the Requirements tab in Software Distribution PST Agent –silent -32bit program  Properties dialog box to specify program requirements, including the client platforms on which the program will run.

Select the Client operating Systems the agent should run on

The 32 bit and 64 bit PST agent programs were advertised to all PC’s, so we selected which agents can run on which operating systems.

Copy the package to a distribution point

1. In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / Computer Management / Software Distribution / Red-Gate Software PST Importer Agent
2. Right-click the Distribution Points node, and then click New Distribution Point.
3. Use the Copy Package Wizard to select the destination distribution point and the package to copy.

Copy the package to a distribution point

4. Verify that the package has copied – navigate to Red-Gate PST Importer / Package Status /Package Status /sitenmame/  -the status should be “installed”

Copy the package to a distribution point

Create an Advertisement

You will need to have a collection for to advertise the program too. Please refer to the Microsoft documentation http://technet.microsoft.com/en-us/library/bb694134.aspx

We used the default “All Windows Workstation or Professional Systems” collection but you can create your own specific collection of PCs

1. In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / Computer Management / Software Distribution.
2. Right-click Advertisements, point to New, and then click Advertisement

Create an Advertisement

3. Use the New Advertisement Wizard to create an advertisement, specifying general information, the collection to which the advertisement should be distributed, the run schedule, and other information for the new advertisement.-

We deployed the tool using a mandatory assignment running at logon and selected “Run program from distribution point”

Create an Advertisement

The mandatory assignment meant that our users were not required to Run the program form advertised tasks. The Agent was deployed to the user without the users interaction

We always advertise tasks at least 10 minutes into the future, to ensure that the task is not out of date when the it reaches the client.

We chose to run the prgoram form our disrtutbion point so the user would not be propeted to download the agent.

Create an Advertisement

Trobuleshooting the Installation

1. View the status of an advertisement

In the Configuration Manager console, navigate to System CenterConfiguration Manager / Site Database / System Status / Advertisement Status.

2. Client Event Viewer

 


Client Event Viewer



Client Event Viewer

 

3.SCCM reports

Report Name- Last 1000 messages for a specific computer (Errors, Warnings, and Information).

SCCM Reports

The report “All advertisements for a specific collection” is also helpful in demitting success:

The report “All advertisements for a specific collection” is also helpful in demitting success

The 144 rejected are 32 bit machines and the 37 succeeded / accepted are 64 bit

The 62 machines are turned off. The 32 bit installer:

The 32 bit installer

System Status -> Advertisement status-

System Status -> Advertisement status-

Msi logs

To troubleshoot installation errors add     “/l*v c:\PSTagent.log” to the msiexec command line.

This week we did a test activation of the SCR replica in our test environment, but ran into an issue that we could not find a documented solution for.  In the hope that it saves someone else some time and anguish I’ve written about it here.

The procedure for activating an SCR copy is pretty well documented on Microsoft TechNet.

Step four in the activation procedure is to run the Exchange 2007 command line setup program, setup.com, to configure the clustered mailbox server on the SCR server.  The command line looks like this:

Setup.com /RecoverCMS /CMSName:<CMS Name> /CMSIPAddress:<IPAddress>

When we ran the command on our SCR server we received this error output:

Clustered Mailbox Server         ……………………. FAILED

Deleting virtual directory ‘IIS://exchangecms.example.com/W3SVC/1/ROOT/Exchange’ on ‘exchangecms’ failed.

The virtual directory ‘Exchange’ already exists under ‘exchangecms.example.com/Default Web Site’.

Parameter name: VirtualDirectoryName

The Exchange Server Setup operation did not complete. For more information, visit http://support.microsoft.com and enter the Error ID.

Exchange Server setup encountered an error.

An event 1002 error was also logged in the Application event log:

Exchange Server component Clustered Mailbox Server failed.

Error: Error:

Deleting virtual directory ‘IIS://exchangecms.example.com/W3SVC/1/ROOT/Exchange’ on ‘exchangecms’ failed.

WMI exception occured on server ‘exchangecms.example.com’: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Error:

The virtual directory ‘Exchange’ already exists under ‘exchangecms.example.com/Default Web Site’.

Parameter name: VirtualDirectoryName

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

There is a similar issue described in this Microsoft Knowledge Base article: http://support.microsoft.com/kb/971713, but that did not help us as the conditions of our situation were different – both our SCR and CCR test servers are in the same AD site.  Nevertheless we checked our DCs and replication and found no problems.

After first checking the obvious things – domain controller replication, DNS and WINS name registrations and resolution, and re-running the command several times, we realised that the SCR server had managed to partially bring up the clustered mailbox server.  The Exchange services had been added to the cluster group, including the cluster name and IP address.  This meant that the server which setup was trying to modify must have been the SCR server itself.  We started IIS manager on the SCR server, and sure enough, the ‘Exchange’ virtual directory did indeed exist under the ‘Default Web Site’.

We removed the three Exchange virtual directories, Exadmin, Exchange, and Public, and re-ran the setup.com command and the process went through without any further errors.

So, if you are trying to activate an SCR replica, and you get an error telling you that the Exchange virtual directories already exist, try removing them on the SCR server.

The cause? An SSL certificate that expired some time last year – the default Exchange self-signed certificate seems to have a default validity of a year, after which you get the warning above when starting Outlook.

The solution turns out to be very simple. In Exchange Management Console, grab a list of your certificates with the “Get-ExchangeCertificate” cmdlet:

You can then view further details by piping the output into the list formatter:

Once you’ve done that, you can renew the certificate. Create a new one by running the following cmdlet ({Thumbprint} is the Thumbprint listed in the details above, or can be ignored if you’ve only got one certificate to start with:

Get-ExchangeCertificate {Thumbprint} | New-ExchangeCertificate

The new certificate will now exist (check with Get-ExchangeCertificate) and will have a new Thumbprint. Now you just need to enable it for IIS’s use:

Enable-ExchangeCertificate -Thumbprint {Thumbprint} -Services “IIS”

You should now see a “W” listed in the services column for that certificate if you run Get-ExchangeCertificate:

Finally, if you wish, you can use Remove-ExchangeCertificate to remove the old one.

Restart Outlook, and it should be happy again!