dinsdag 31 januari 2012

Microsoft Exchange PST Capture tool released!

PST Capture is used to discover and import Outlook Personal Folder (.pst) File Format files into Exchange Server and Exchange Online. PST Capture helps an organization that wishes to gain more control over their email data repositories by placing them into Exchange. By optionally installing PST Capture Agents on target machines, administrators can determine where .pst files are located and who their file owner is via the PST Capture Console. Administrators can import .pst files via Import Lists to Exchange Server or Exchange Online. Data can be directly imported into the primary mailbox or associated archive mailbox.

A quote from technet:
"Microsoft Exchange PST Capture

Microsoft Exchange PST Capture allows you to search for PST files on computers in your organization and then import those files to mailboxes in your organization. PST Capture works with both on-premises Exchange servers and Exchange Online.
This topic provides an overview of PST Capture. For details about how to install PST Capture, see Install PST Capture.

 PST Capture Architecture

PST Capture is comprised of the following components:
PST Capture Central Service   At the heart of PST Capture is the PST Capture Central Service. The Central Service maintains the list of all PST files found in your organization and manages the data as it’s moved to the Exchange servers or Exchange Online.

PST Capture Agent   Discovery of the PST files is performed by PST Capture agents that are installed on computers in your organization. The agents also send the PST files they find to the host computer when an import operation is started on the PST Capture Console.
PST Capture Console   The PST Capture Console is the interface you use to configure PST searches, specify the target mailboxes for PST files, and track the status of PST import operations and reports. You can also use the console to import PST files stored on network attached storage (NAS) devices, on which you can’t install PST agents.

For optimal operation, you should install the PST Capture Central Service and the PST Capture Console on a dedicated computer, known as the PST Capture host computer.
Communication between the PST Capture Central Service and the PST Capture agents is achieved through a polling mechanism. Each minute, all PST Capture agents poll the Central Service for configuration updates and any pending tasks by default. If necessary, you can change this polling frequency (for details, see Configure PST Capture Settings). When a PST Capture agent contacts the Central Service, it receives any pending actions, such as a PST search or import operation. The PST Capture Agent then sends status updates from previous actions to the Central Service.

 PST Search and PST Import Operations

When you configure and run a PST search from the PST Capture Console, a new PST search action is queued for the PST agents that are installed on the computers included in the search. These agents scan the local computers on which they are installed for PST files and then return the list of PST files that were located to the Central Service. For detailed steps about how to perform a PST search, see Search for PSTs Using PST Capture.
When you configure and run an import operation, a new import action is queued for the PST agents that are installed on the computers where the PST files reside. These agents transmit the PST files to the Central Service. The Central Service then logs on to the destination mailboxes and imports the data. For detailed steps about how to import PSTs, see Import PSTs using PST Capture.

 Network Utilization

When using PST Capture, the greatest impact on network utilization is when the actual PST data is being transmitted over the network. When you import a PST file to a mailbox, it is first copied from the client computer where the PST Capture agent is installed to the staging area on the host computer where PST Capture Console is installed.
If you import PSTs to your on-premises mailboxes, the PST data is sent to your Exchange organization through your Client Access servers. Therefore, as a best practice, we recommend that the network connection between the host computer and your Exchange servers is a low latency, high bandwidth connection.
If you import PSTs to your cloud-based mailboxes, the PST data is sent directly to the cloud from the host computer.
Because the movement of PSTs over the network can consume a lot of bandwidth, you may want to schedule the PST import operations during off hours. This is especially true if you have a low bandwidth connection between the host computer and the client computers, such as branch office scenarios.

 Permission Considerations for PST Capture

PST Capture requires a service account. Depending on how you use PST Capture, a different set of permissions is required for the service account. The following table provides the permission requirements for each usage scenario.

System requirements :
Supported Operating Systems: Windows Server 2008 R2 Enterprise
  • Review the Technical Documentation prior to installation of Microsoft Exchange PST Capture
  • Exchange Server 2010, if used to import to Exchange Server 2010 mailboxes or archives
  • Exchange Online (Office 365) subscription if used to import to Exchange Online (Office 365) mailboxes or archives
  • Microsoft .NET Framework 3.5 or 3.5 Service Pack 1 (SP1)
  • Microsoft Outlook 2010 x64 (only required on the host computer where you install the Central Service and Console)

Links to technet :
How to install PST capture :
Search for PSTs using PST Capture :
Import PSTs using PST Capture :
Configure PST Capture settings :

PST Capture can be found here :
Introduction video for PST Capture:

Here is a screen for the tool with some pointers on where to find which functions.
Please click for full ( readable ) size.

vrijdag 27 januari 2012

Office 365 Publishing ADFS 2.0 using TMG / ISA

At first, we used a seperate ADFS proxy for external requests requests to our ADFS server.
Since we have a TMG in place, we wanted to get rid of our ADFS proxy and start using TMG for external requests to our ADFS.

We currently have a ADFS farm with 2 members, load balanced by using Windows NLB.

The screens below describe the process of making a Web Publishing Rule in TMG for ADFS services and a Web Listener.

Give your web publishing rule a name according to your rule naming convention.
Click next.

Select "Allow" and click next.

Input you internal site name, we use split DNS and our internal NLB cluster name is the same as our internal ADFS name, so the internal site name is the same as the external.
Input your NLB cluster ip address in the ip address section, in case TMG cannot resolve the name.
Click next.

Input the path for ADFS, this is /adfs/*.
Select "Forward the original host header" and click next.

Input you public name details, public name corresponds to you external ADFS name, the path is the same as your internal publising details. Click next.

You probably dont have a web listener yet for ADFS, click new to set up a new web listener.

In the new web listener wizard, give the web listener a name that corresponds to your web listener naming convention and click next.

Select do not require SSL and click next.

Select your external IP address for your ADFS site and click next.

Select the certificate used for ADFS ( sts.domain.com ) and click next.
I you haven't requested a certificate yet, refer to the certificate planning blog at technet.

Because we want to use form based authentication for external users, select HTLM Form Authentication allong with Windows ( active directory ) and click next.

Click next.

Now you are finished setting up the web listener, now you need to finish the publishing rule wizard.

Select the listener for ADFS you just created, click next.

For authentication, select NTLM authentication and click next.

Select all users in the user sets, because we want all users to be able to connect to the site.
Click next.

Now the publishing rule wizard is also completed, click finish to create the publishing rule.

Also verify if you have normalization and block high bit characters disabled.
Right click your rule and choose configure http.

Also, open the properties of the publishing rule and browse to the link translation tab.
Make sure the " Apply link translation to this rule"  is unchecked.
Otherwise you may receive the error " your organization could not sign you in to this service " when signing in to webmail or the portal.
Don't forget to save your configuration by applying your configuration.

Click finish and you're done!
Now when you are externally connecting to your webmail ( https://outlook.com/domain.com ) you get redirected to your ADFS hostname configured in Office 365.
Below is the form shown by TMG.

In this form based logon you can also enable changing your password and expiry notifications.
These are features not built in ADFS proxy, but you can use these when using TMG.
These settings can me configured in the web listener properties in the forms tab.

Hope this helps!

woensdag 25 januari 2012

Managing Office 365 with Powershell

I came accross an interesting blogpost where all the Powershell cmdlets for managing Office 365 are summed-up in several links. For every category of "management" there is a link where powershell cmdlets are provided.
Below you will find the blogpost, and an url to the original blogpost / poster.

"I've seen a number of questions from Office 365 users about issues with performing administrative tasks such as managing domains, users, groups, and subscriptions via the normal web user interface. If you should ever have an issue with Office 365 be sure to consider using the PowerShell cmdlets provided by Microsoft to resolve your issues.

Click one of the following links to find the cmdlets for a particular Office 365 management task, or to learn more about Microsoft Exchange Online cmdlets."

Source : http://community.office365.com/en-us/b/office_365_technical_blog/archive/2012/01/24/tuesday-s-tip-office-365-and-powershell-grid-user-post.aspx

vrijdag 6 januari 2012

Failed to find a valid mailbox database after removing first default mailbox database in Exchange 2010

Recently we deleted our first default mailbox database and migrated to another database.
Afterwards we had issues when creating new mailboxes.
In the New Mailbox wizard you can set the mailbox database you want the mailbox to go to, if you do now choose a mailbox database, the wizard wil automatically fallback to the default mailbox database.
In our case, it did not because the wizard could not find a valid database anymore.

When doing a get-mailboxdatabase we noticed that the "IsExcludedFromProvisioning" parameter was set to True.
For easy viewing, you can do a :
Get-MailboxDatabase | fl isexcludedfromprovisioning, issuspendedfromprovisioning
With this command you only view the relevant parameters for this issue.

As said before, in my case IsExcludedFromProvisioning was set to true and therefore New-Mailbox requests where i did not specify a mailbox database failed.
To resolve this, the only thing you have to do is set this parameter to false.
Do this with the Set-MailboxDatabase "database" -IsExcludedFromProvisioning $false command.

To verify the parameter has changed, redo the get command to show the 2 parameters.

Now you are all set!
New-Mailbox requests will now complete succesfully, even if you don't specify a mailbox database in the wizard.