Parative - Offering Migration management, infrastructure services, quest preferred partners using Quest software, Microsoft IO, Virtualization and Training

September 2010
M	T	W	T	F	S	S
« Aug
	1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30

Installing Blackberry Express with Exchange 2010 – Part 1

August 5, 2010 – 9:42 am

Today I am going to have a look at what is involved in installing Blackberry Express Server 5.0 with Exchange Server 2010.

What is Blackberry Express Server

Blackberry Express Server is supported to be installed directly on an Exchange 2003 SP2, 2007 SP1 or 2010 RU1 server in order to support up to 75 Blackberry Smartphones and is ideal for users who receive between 100 and 200 messages per day. Blackberry Express Server can be deployed to dedicated hardware for support up to 2,000 Smartphones. The only requirement for using Blackberry Express Server is that you have Internet enabled data plans with your Blackberry Devices.

Operating System Requirements for v5.0.1

Windows Server 2003 SP2 (32-bit or 64-bit)
Windows Server 2k3 R2 SP2 (32-bit or 64-bit)
Windows Server 2008 (32-bit or 64-bit)
Windows Server 2008 R2 (Except for Administration and Monitor components)
Windows Small Business Server 2003 or 2008

Hardware Requirements

User Support	Requirements
Up to 75 Users hosted on Exchange Server or SBS	Standard Exchange / SBS Scaling + 1.5 GB RAM
Up to 200 Users	Single Processor 2.0 GHz Xeon (two processors recommended) 2GB RAM 2 Drives (RAID 1)
Up to 500 Users	Two Processors, 2.0 GHz Xeon 2GB RAM 2 Drives (RAID 1)
Up to 1000 Users	Two Processors, 2.0 GHz Xeon 3GB RAM 2 Drives (RAID 1)
Up to 2000 Users	Two Processors, 2.8 GHz Xeon 6GB RAM 2 Drives (RAID 1) or 4 Drives RAID10

Messaging Platform Requirements

Microsoft Exchange 2010 with Rollup 1
Microsoft Exchange 2007 SP2
Microsoft Exchange 2003 SP2
Microsoft Exchange mixed environment (Exchange 2003 and 2007)

Software Requirements

Blackberry Enterprise Server Express requires one of the following software components

Microsoft Exchange 2003 SP2 System Manager
Microsoft Exchange MAPI Client and CDO 1.21 (CDO 1.21 Version 6.5.8146.0 or higher for Exchange 2010)

There are other requirements such as Java components but the Blackberry Express Server installation package can install those for you if they are not detected.

Database Requirements

Access to one of the following SQL servers

Supported SQL Servers	Database Server settings
MSDE 2000 SP3 MS SQL Server 2005 SP3 (32-bit or 64-bit) MS SQL Server 2005 Express SP3 MS SQL Server 2008 SP1 (32-bit or 64-bit) MS SQL Server 2008 Express SP1 (32-bit or 64-bit)	Collation set to default case-insensitive Blackberry Configuration database collation set to default case-insensitive Blackberry database notification system and Microsoft SQL Server collation must be the same. Default collations are recommended though non-default collations are supported. TCP/IP Protocols turned on If using a remote database server ensure remote connections are enabled.

Configuring for Exchange 2010

Create a Service Account

Ideally in the domain where the Blackberry Enterprise Express server is to be installed create a domain account with a mailbox called BESAdmin.
Assign BESAdmin owner permissions to all Public Folders. BES requires public folders to support free/busy lookups.
BESAdmin must not be a member of Domain Admins.

Service Account Permissions

Run the following command to set store permissions for the BESAdmin account (this will need to be repeated if a new mailbox database is created in Exchange)

Get-MailboxDatabase | Add-ADPermission -user "BESAdmin" -accessrights extendedright -extendedrights receive-as,ms-exch-store-admin

Add the BESAdmin account to the View-one organization management role which allows the service account to see the Exchange configuration objects within Active Directory

Add-RoleGroupMember “View-only organization management” –member “BESAdmin”

The BESAdmin account also needs to be granted rights to be able to Send-as a user. The permission can be set at the domain level and allowed to inherit down.

Add-AdPermission example.com –inheritedobjecttype user –inheritancetype descendents –extendedrights send-as –user “BESAdmin”

Exchange Configuration

Client Throttling

Client throttling can affect performance of the Blackberry Enterprise Server so the throttling policy for the BESAdmin account should be modified so that it can be adjusted if required without affecting all users.

New-ThrottlingPolicy BESPolicy
Set-Mailbox “BESAdmin” –throttlingpolicy BESPolicy

Address Book Service Connections

The number of maximum number of address book service connections needs to be increased from 50 to 100000. This change affects all users

Browse to the Exchange install location. By default this is C:\Program Files\Microsoft\Exchange Server\V14 and locate the file Microsoft.exchange.addressbook.service.exe.config under the BIN folder on each CAS server. Open this file in a text editor such as Notepad.

Locate and change MaxSessionsPerUser to 100000
Save and close the file and restart the Microsoft Exchange Address Book service.

Create Management Exchange 2010 Role Entry

Configure Management role entry for Exchange Web Services which allows the management of calendars
New-ManagementRoleAssignment –name “BES Admin EWS” –role applicationImpersonation –user “BESAdmin”

Configure Admin account encryption level (Blackberry Enterprise Express 5.0 pre SP1)

If you are running in a forest which has Windows Server 2008 Domain Controllers but the domain functional level is pre-Windows 2008 you may run into a problem where the account designated as the administrator account is unable to login to the Blackberry Administration Console.

The options are

Upgrade to Blackberry Enterprise Server Express 5.0 SP1 (Bundle 12)
Upgrade domain functional level to Windows 2008 (not reversible)
Configure the use of Kerberos DES encryption on Admin account account tab in Active Directory Users & Computers. This is the option I have chosen as part of the install process as I don’t have BES Express 5.0 SP1 to hand and I did not wish to update my domain to Windows 2008 just yet.

Configure SQL Server Permissions

The account used to install the Blackberry Enterprise Server Express software needs to be granted dbcreator rights on the SQL server hosting the Blackberry Configuration database (I install as the BESAdmin account as that ensures the service account has the correct connection). Additionally the BESAdmin account also needs sysadmin rights on the SQL server if the notification system is going to be used.

Firewalls and Network Requirements

The Blackberry Enterprise Server Express needs the following requirements to be met

Bi-directional use of port 3101 in order to maintain an outbound connection to an external server.
Access to a DNS server which can resolve internet addresses.
For proxy firewalls the proxy server needs to be transparent.

That’s all for the moment. I will follow up shortly with another post which quickly runs through the Blackberry Enterprise Server Express install process.

By GaryWilkins | Posted in Exchange, Unified Communications | Comments (0)

Exchange 2010 Remote PowerShell

February 23, 2010 – 7:44 pm

It has been a while since I have posted so here goes for the first post of 2010.

PowerShell v2 has brought with it the ability to connect from remote machines as PowerShell is made available via an IIS published URL. This allows support engineers to connect to PowerShell over the internet and administer servers without having to open a VPN to the enterprise network.

I have been looking for a while around how to achieve this from a non-domain joined workstation so that I could administer client systems. Information on the internet never seemed to give the complete picture so I have documented it here. This example is connecting to Exchange Server 2010.

Step 1. Enable Remote PowerShell

Remote PowerShell first needs to be enabled on the Exchange 2010 CAS servers which are internet facing. This can be achieve by using the PowerShell command enable-psremoting.

The command describes what it is going to do and then prompts for confirmation on a couple of actions including a restart of the WinRM service.

Step 2. Enable Remote PowerShell for users

Remote PowerShell is enabled by default on user objects. You can confirm that is enabled by running the command: get-user –id <userID> ¦ select displayname,remotepowershellenabled ¦ fl

The command set-user –id <userID> –remotepowershellenabled:$true will enable remote PowerShell for a user.

Step 3. Enable Authentication on the IIS Web Site

We normally publish the Exchange CAS servers through Microsoft ISA Server 2006. By default the PowerShell virtual directory is enabled for Anonymous authentication only. Open IIS Manager on the Exchange 2010 CAS server, open the Authentication settings of the PowerShell virtual directory and enable Basic Authentication.

Step 4. Publish the PowerShell Virtual Directory on ISA Server

As previously mentioned Exchange CAS servers are normally deployed behind a Microsoft ISA Server. Adding the PowerShell virtual directory to the publishing rules for Outlook Web App will expose the location to the internet. We normally have to ISA policies publishing OWA, one for Negotiated Authentication and one for Basic Authentication. The PowerShell virtual directory will need to be published via the Basic Authentication publishing rule.

That completes the configurations required to expose PowerShell to the internet. All that remains the establishing the connection to Exchange Server over the internet from PowerShell v2 installed on my workstation.

Step 5 – Set Session Options

If you are testing Remote PowerShell to a Proof of Concept or a live system that is still utilizing self-signed certificates you may need to establish some session options for the connection.

Open a PowerShell v2 Window on your client machine and enter the following (don’t close the PowerShell Window between the steps below)

$so = new-pssessionoption –skiprevocationcheck –skipcncheck -skipcacheck

These options will allow the connection to ignore common problems when making connections while using self-signed certificates.

Step 6 – Enter Credentials

In order to connect you need to enter some credentials in order to login to the remote system. This can be achieved by entering the command: $Cred = Get-Credential

In the dialog enter the credentials of a user who has remote PowerShell rights and also rights to administer Exchange set through the Role Based Access Control (RBAC).

Step 7 – Create a Remote PowerShell Session

Next we use the Session Options and the Credentials entered in the previous steps to establish the session with one of the CAS servers published through the ISA Server.

Enter the command: $PSSession = new-pssession –configurationname Microsoft.Exchange –connectionuri “https://<External FQDN>/PowerShell” –credential $Cred –authentication Basic –SessionOption $so

Where <External FQDN> is the internet address of your Exchange servers.

Step 8 – Import the Remote PowerShell Session

The final step in the connection process is to import the session. This downloads the commands that you are allowed to use from the Exchange Servers. Only the commands that you are allowed to use based on your RBAC privileges are downloaded and made available.

To import the PowerShell session type the command : import-pssession $PSsession

A cyan progress bar will appear at the top of the screen while the commands are downloaded.

Step 9 – Use Remote PowerShell

Once the command download is complete you can use Exchange PowerShell commands to administer the servers over the internet.

Step 10 – Close the Remote PowerShell session

When you have completed your tasks at hand the PowerShell session should ideally be closed gracefully using the command : remove-pssession $PSSession

That’s it for this article see you next time.

By GaryWilkins | Posted in Exchange | Comments (0)

Quest QMM and Exchange Server 2007 SP2

November 16, 2009 – 2:04 pm

An interesting development occured this week where we have found that Quest Migration Manager for Exchange v8.3 is not compatible with Exchange Server 2007 SP2 for customers who are running this QMM version and are tempted to upgrade their Exchange server versions.

As of the time of writting, Out of the Box QMM v8.4 is also not supported against Exchange Server 2007 SP2 however Quest have released an update for QMM v8.4 which patches the SQL database to make it compatible and supported with Exchange Server 2007 SP2.

When deploying QMM v8.4 install the Hotfix: MigrationManagerForExchange8.4Update20090828. It is not supported in deploy this hotfix against QMM v8.3.

This hotfix does not imply support with QMM for Exchange 2010 and does not synchronize any new attributes introduced as part of the Exchange 2010 schema updates which form part of Exchange 2007 SP2.

By GaryWilkins | Posted in Unified Communications | Tagged 2007, Exchange, Hotfix, QMM, Quest, SP2 | Comments (0)

Exchange 2010 is Code Complete

October 9, 2009 – 2:03 pm

It has been announced that the final code for Exchange Server 2010 has been signed off as complete so it should be with us soon as this is a big milestone towards RTM. By the looks of things Microsoft may launch Exchange Server 2010 at TechED Europe.

The announcement can be found on the Exchange Team Blog Here

By GaryWilkins | Posted in Unified Communications | Tagged 2010, Exchange, RTM | Comments (0)

Exchange Server 2010 Mailbox Database High Availability and Goodbye Exchange Clustering as we know it.

August 11, 2009 – 4:03 pm

Exchange Server clustering has been with us since Exchange Server 5.5 but left Exchange Administrators having to know the complexities of Microsoft Clustering and Microsoft Exchange in order to support it. With the advent of Exchange Server 2007 Microsoft introduced new clustering options to the Exchange server product line that gave messaging architects increased flexibility in deploying highly available systems, but there were still limitations such as:

Site failover was not seamless due to the DNS TTL.
Fail over could take minutes.
There are scenarios where message loss could occur.
The cluster had to be built before the installation of Exchange. If a cluster was required after the installation of Exchange another server had to be built.
Failover was restricted to the server level so if one database failed then all databases failed over.

Microsoft are acknowledging with Exchange Server 2010 that the configuration and support of the Windows Cluster required additional skill sets and added complexity to the server build and ongoing support. With Exchange Server 2010 Exchange clustering as we know it and replaced it with the Database Availability Group (DAG) which combines and improves on the best parts of the CCR and SCR technologies from Exchange Server 2007. The benefits of a DAG are as follows:

Allows multiple copies of the same database on different servers
Failover is at the database level.
Failover time is around 30 seconds.
Better tracking of the delivery of messages and only uncommitted messages are retained in the Hub Dumpster.
High availability options can be deployed after initial install.

To assist with the creation of the Database Availability Group there has been another fundamental change to Exchange Server 2010 which is that the MAPI end point for Outlook access has now been moved onto the CAS role, this provides users with a single access point for client requests no matter which server their mailbox is active on. For multiple CAS server deployments a CAS array needs to be configured which I have talked about in a previous post.

As previously mentioned the DAG is configured after initial install and still uses components from Windows failover-clustering however the difference now is that Exchange Server will configure the clustering options that it needs for you as part of the DAG creation so the Exchange engineer only needs to know how to configure the DAG.

Database availability groups can consist of up to 16 servers and within each DAG there can be up to 16 copies of any given mailbox database. The DAG uses the log shipping technology introduced with Exchange server 2007 to maintain copies of the database on multiple servers for which differing log replay times can be configured (up to 1 week lag).

Each copy of the database is given a “Preferred List Sequence Number”, this is essentially tells the CAS server in which priority it should try and connect to the database and also the order in which the DAG will try to fail over to the next copy of the database, so if the database with Sequence Number 1 fails, the DAG will bring the database with Sequence Number 2 online and so on. The CAS server will then route requests for that database to server with the online copy of the database.

So in the diagram above if the database DB1 on Server 1 goes offline then the Database Availability Group will automatically bring the DB1 database copy on Server 2 online and so on with Server 4 should the database on Server 2 not be available. A time of around 30 seconds is being mentioned for a database copy to be brought online by the DAG.

The diagram above shows a four server DAG with copies of the database distributed across the servers. The general advice currently from Microsoft is to have fewer large DAG’s rather than a large number of smaller DAG’s. The database does not have to be replicated to all or any servers depending on requirements. In distributed environments the placement of database copies could be quite important.

As the client is now connecting in via the CAS server, they should not experience any disconnection from the server but there will be a short outage will the database copy is brought online.

With respect to Public Folder databases, these are not replicated between servers by the Database Availability Group. Public Folder high availability still relies on Public Folder Replication between servers.

With regard to the Hub Transport Dumpster this has also been optimized for the new failover model and messages are only retained in the dumpster until it is recorded that the message has been replicated to all database copies, this assists with bringing the database copies online as only messages that have not been replicated need to be requested from the Dumpster.

By GaryWilkins | Posted in Unified Communications | Tagged 2010, Cluster, DAG, Exchange | Comments (0)

Exchange 2010 & CAS Array with NLB

July 15, 2009 – 2:02 pm

When I first started to seriously look at the Beta version of Exchange 2010 that has been released by Microsoft I saw the term CAS Array mentioned in various articles on the internet but not a clear definition of what an CAS Array is or how to configure it so I had a look into it in our Exchange 2010 lab.

In simple terms a CAS Array is a set of Exchange 2010 CAS servers that are load balanced using either Windows Network Load Balancing, Microsoft ISA Server or a third party load balancing appliance. For the vast majority of the CAS functions this is very similar to load balancing the CAS role in an Exchange 2007 Organization.

However with the advent of Exchange Server 2010 the MAPI endpoint has also now been moved onto the CAS role and is no longer on the Mailbox role as was the case with all previous versions of Exchange Server. Without configuring a CAS Array the Outlook client will connect to a single CAS server within the Active Directory Site and the connection would fail should that CAS server go offline.

So the array configuration takes two steps which are:

1. Configure the CAS servers in a Windows Network Load Balancing cluster.
2. Configure the CAS Array in Exchange.

It is also worth mentioning now that with Exchange 2010 that what we have known in the past for Exchange clustering has now been replaced by Database Availability Groups (DAG) and that CAS and HUB roles can now be collocated with the Mailbox role when a DAG is configured. However DAGs still utilize components of Windows failover-clustering and as such should not be mixed with the Network Load Balancing that comes with Windows Server. In these instances Microsoft ISA server or a 3rd party appliance would have to be used to provide the load balancing functionality and the CAS Array configured to point to these devices.

Step 1 – Configuring the NLB

I am not going to re-invent the wheel here as Henrik Walther already has a very good article on creating an NLB for CAS servers here. I created an NLB with two Exchange 2010 CAS servers using the FQDN internalarray2.2k10.dom as the NLB cluster address.

The only difference that I made over what Henrik Walther describes for the NLB setup is that in order to accommodate MAPI connectivity on the CAS role through the NLB I added in a port range for TCP port 135 to expose the RPC endpoints and for the port range TCP 1024-65535 as I did not know which port the MAPI endpoint was being published or if the port used by the Exchange 2010 CAS server for MAPI can be fixed.

Step 2 – Configuring the CAS Array

Configuring the CAS Array is quite straight forward and can be done with few Powershell commands.

1. Open up Exchange 2010 Powershell
2.Type in this command to create the CAS Array in the Exchange organization

syntax : new-clientaccessarray –name <name of array> –fqdn <DNS FQDN of the Array>

Example : new-clientaccessarray –name “InternalArray1” –fqdn internalarray1.2k10.dom

It is worth noting here that there can be only one CAS array configured per Active Directory Site. Also while creating a new Mailbox database in the AD site, the value for the CAS Array was automatically picked up.

3. The next Powershell command to run sets an attribute on the mailbox database its self. This attribute is used to tell connecting clients which FQDN they should connect to in order to access this database.

This example sets the value on all mailbox databases…

syntax : get-mailboxdatabase | set-mailboxdatabase –rpcclientaccessserver <DNS FQDN of the Array>

Example : get-mailboxdatabase | set-mailboxdatabase –rpcclientaccessserver internalarray1.2k10.dom

4. Finally the setting can be checked using Powershell as can be seen in the above example

Example : get-mailboxdatabase | select name,rpcclientaccessserver | fl

Checking client Access

The last step is to verify that client access is using the new URL so I created a new Microsoft Outlook profile using the CAS Array FQDN as the server name and typed in the details of a test user. As can be seen in the screen shot below, the profile creation was successful.

This article was written based on Microsoft Exchange Server 2010 Beta 1 and as such is subject to possible change as software features may be added or removed.

By GaryWilkins | Posted in Unified Communications | Tagged 2010, Array, CAS, E14, Exchange | Comments (2)

Dealing with QMM and the Inter-Organizational Replication Tool (Part 2)

June 15, 2009 – 2:00 pm

In my previous post on this topic I discussed at a high level how the Inter-Organizational Replication tool works to synchronize Free/Busy information between Exchange Organizations and then discussed some of the problems that could occur at a later date if a migration was then attempted to consolidate the Exchange Organizations.

In this post I will discus how to resolve this problem so that a tool such as Quest Migration Manager for Exchange (QMM-EX) can be implemented and continue to synchronize Free/Busy information as it is not supported to run the two tools in parallel.

The first problem that we have to do is remove any Free/Busy messages from the Exchange Organization in Domain A for objects from the Exchange Organization in Domain B and vice-versa.

One way of doing this is to use the utility MFCMAPI to open up the relevant section of the Schedule+ Free/Busy Public Folder and simply delete the Free/Busy messages. This is fairly straight forward and quick to do but does lead to an unavailability of Free/Busy information within the Exchange Organization.

If we were now to enable the calendaring agents within QMM-EX again now we would hit upon another problem that can badly effect Exchange migrations if it is not carefully considered not just within Calendar Migration but also within Public Folder migrations. Within the log files we would see SYNC_E_OBJECT_DELETED errors.

Basically what is happening here is that QMM-EX is trying to re-create the Free/Busy message in the target Public Folder Database but it can’t as the PR_SOURCE_KEY already exists. But did we not delete it?

The problem here is that when objects are deleted in the Public Folder database they are not actually deleted. Similar to other components of Microsoft systems the objects in the Public Folder tree are actually tombstoned to be permanently removed after the tombstone expiration interval. As such QMM-EX is unable to create another object with the same PR_SOURCE_KEY.

So what are the options? We could reduce the tombstone expiration interval to 1 day which would may be fine in a small environment, but there is another consideration here in that only 500 tombstoned objects are removed per day. So if there are thousands of Free/Busy messages there would be a waiting game while the objects clear out of the database, all the time remember though users are being impacted as Free/Busy information has been removed.

The only way of speeding this up is to change the PR_SOURCE_KEY of the Free/Busy messages in their relevant source Exchange environments but we can’t just go and change the value of the PR_SOURCE_KEY.

The solution is in the use of a utility that is only available from Microsoft Support. The GUI version is called UpdateFB.exe and there is a command line version called CPPCDO.exe. These utilities can be used to rebuild Free/Busy information based on the content of mailbox calendars but before running through this process we have to delete the remaining Free/Busy messages for users using MFCMAPI as we did earlier in each Exchange Organization for the users from the source Exchange Organizations.

Figure 1 – GUI Version of UpdateFB.exe

We now have in the example described in Part 1 of this article two Exchange Organizations with no Free/Busy information. The first task when using UpdateFB.Exe is to generate an import file for the mailboxes we want the utility to process, the import file needs to contain the alias of each mailbox and the NetBIOS name of the Exchange server where the mailbox is homed. When we run the UpdateFB.Exe utility with a suitable service account it will go through all of the mailboxes specified in it’s import file and rebuild the Free/Busy information based on mailbox calendars and the Free/Busy messages will be recreated with a new PR_SOURCE_KEY which means that when QMM tries to synchronize these messages it will be successful.

Figure2 – Sample UpdateFB,exe import file.

Once UpdateFB.exe has completed it would then be possible to start the calendar synchronization jobs within QMM as all of the Free/Busy messages would have new PR_SOURCE_KEY values that can be synchronized and correctly associated with the migrating users in the target domain.

This process needs to be carefully considered with other QMM associated processes and the sequence of events carefully worked out and tested to ensure that the disruption to users is reduced to the minimum possible time.

I would like to stress at this point that this is a disruptive process that must be tested and have valid backups of the Exchange environment before you try to implement this in a live environment. When you get to a live environment with this type of process you need to know that there is a good chance that everything will be ok with the process and the use of consultancy is advised.

By GaryWilkins | Posted in Exchange | Tagged Exchange, Migration, QMM, UpdateDB | Comments (2)

Dealing with QMM and the Inter-Organizational Replication Tool (Part 1)

May 13, 2009 – 10:00 am

Some organizations that are going through a merger or looking to consolidate Exchange organizations may choose to quickly install the Inter-Organizational replication tool so that Free/busy and Public Folder replication can be provided between the Exchange Organizations and then look to migrate one organization into the other at a later date using a product such as Quest Migration Manager for Exchange (QMM-EX).

The inter-organizational replication tool may be set up as shown in the following diagram where contacts are created to create a GAL in the opposing Exchange organizations and then the inter-organizational replication tool associates Free/Busy information with the contacts.

In order to understand the problem when it comes to QMM we also need to understand a bit further about how Free/Busy information is stored in Exchange Server and also how the inter-organizational replication tool synchronizes these messages.

Free/Busy information in all current versions of Exchange is stored in a System Public Folder called the Schedule+ Free/Busy. I am assuming here that Exchange 2007 is in a mixed environment with a Public Folder store and that it is appropriately configured.

If you use a utility such as MFCMAPI to open up the Schedule+ Free/Busy once the inter-organizational replication tool is in place you would see something similar to this.

If you went on to open one of the EX: folders under the Schedule+ FREE BUSY folder with MFCMAPI you would see a list of all of the Free/Busy messages related to that Exchange Organization/Administrative Group.

Without going into an in depth technical discussion over Free/Busy all we need to know at this point is that each Free/Busy message is associated with an Mail Enabled object using the LegacyExchangeDN attribute which is an internal and unique identifier which is used internally by Exchange Server. We also need to understand that objects stored within the Exchange Server databases have a property called PR_SOURCE_KEY. The PR_SOURCE_KEY is a Globally Unique IDentifier within the Exchange Organization.

The inter-organizational replication tool uses the LegacyExchangeDN attribute to associate Free/Busy messages with the contacts that are created in the opposing environments and then uses the PR_SOURCE_KEY attribute to find and synchronize the actual Free/Busy data.

A period of time can now go by where the inter-organizational replication tool quite happily synchronizes Free/Busy information before a migration project starts in order to consolidate Exchange Organizations.

I am now going to talk about the impact that this has on QMM-EX although it probably applies to similar tools from other vendors as well.

QMM-EX had has Calendar and Free/Busy synchronization built in but I need to take a small step back first at this point and actually talk about Quest Migration Manager for AD (QMM-AD). In this sort of scenario, if we say we wish to merge mailboxes from Domain B into Domain A we would use QMM-AD to migrate the user object from Domain B to Domain A. During this process QMM-AD would detect that there is an existing contact for the user from Domain B in Domain A and as such QMM-AD would create the new user account and then merge the relevant details from the contact onto the user account in Domain A before deleting the contact. The LegacyExchangeDN from the contact is turned into an X500 address and added to the new Domain A users email addresses to allow Exchange users to continue to reply-to this user. I am not going to touch any further on the email routing technicalities here as it is outside the scope of this article.

As Quest do not support synchronization products that provide similar functionality running alongside QMM we are also having to replace the contacts and Free/Busy information that is currently synchronized into Domain B and the graphic below shows how the domains look after the accounts have been migrated with QMM-AD and the contacts deleted.

The problem we have now though as we mentioned earlier is that Free/Busy messages held within Public Folders are associated with a LegacyExchangeDN, and what we have done with the QMM-AD migration is deleted the contact and its LegacyExchangeDN attribute from the Exchange organization and effectively orphaned the Free/Busy objects from any mail enabled objects in Exchange.

If were now to proceed down the route of implementing the calendaring agents within QMM-EX, they would quite happily synchronize the Free/Busy information as they work in a similar way to the inter-organizational replication tool by using the PR_SOURCE_KEY attribute to identify objects in the Exchange Stores. In this scenario the only problem is that the Free/Busy messages are still not associated with any mail enabled objects and as such users would not see any Free/Busy information.

So how do we fix this problem?

In the next part we will discuss how to resolve this problem with Free/Busy messages that have been generated by the inter-organizational replication tool but where we now wish to implement QMM.

By GaryWilkins | Posted in Exchange | Tagged Exchange, Migration, QMM, Quest, UpdateFB.exe | Comments (1)

First Look at the Exchange 2010 (formally known as E14 or Exchange 14) Installation

April 17, 2009 – 2:00 pm

I installed the beta1 release of Exchange 2010 into a lab today and I thought that I would share screen shots of the installation process. The installation process is almost identical to Exchange 2007.

First important point is that Exchange 2010 only installs on to Windows Server 2008. There are a number of Windows Server features that need to be installed as well as additional components downloaded from Microsoft. The requirements vary by role, but to install the Hub, Cas and Mailbox roles onto a single server the following patches had to be applied:

KB950099, KB950888, KB951725, KB958178, Powershell v2 CTP, Office 2007 Filterpack, ASPAJAXExtSetup, .Net Framework v3.5

As can be seen the install process is very similar to Exchange 2007. On my VMWare Server v2 Lab with (AMD X2 2.4GHz, 1.5Gb RAM) allocated to the virtual machine the install process for all roles took a shade under two hours with the hub role seeming to take the most amount of time to install.

Below is the Exchange 2010 Management console, which again is pretty similar to Exchange 2007.

I will be looking at Exchange 2010 some more in future articles.

By GaryWilkins | Posted in Infrastructure Solutions | Tagged 2010, Beta, E14, Exchange | Comments (0)

Exchange 2010 (E14) Public Beta is here

April 15, 2009 – 2:42 pm

Technorati Tags: E14,Exchange 14,Exchange,Beta

The public beta of Exchange 2010 (referred to as Exchange 14 or E14) has been made available on the Microsoft Downloads site. Of course as this is beta software it should not be used in a production environment.

The public beta can be downloaded from here
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1898ed2c-2f88-48ac-824e-d3d20fad77d7