May 2010 - Posts

• Issues to be considered while thinking about moving mailboxes to Exchange 2010 using the Microsoft native tools

  Below is a table of the issues to be considered while thinking about moving mailboxes using the Microsoft native tools in both the 'upgrade' and 'deployment' scenarios supported by Microsoft. Note: If you're using the Priasoft Migration Suite for Exchange this article does not apply to you. Exchange 2003 to 2010 You need to use "move request" cmdlets in 2010 shell to move the mailboxes. Move requests are performed by the Microsoft Exchange Mailbox Replication Service (MRS) that runs on all Client Access servers (CAS). Therefore, CAS servers are busy moving mailboxes and not servicing clients' requests. If you implement Exchange 2010 as an upgrade, some features of Exchange 2010 will not be available until the migration is completed and the organization in moved to a native mode state. You must never try to manage a 2010 mailbox using a 2003 management tool or snap in You can't use 2003 System Manager. You must be careful to use a split administration model while co-existing to not cause problems with migrated objects. The mailbox move is offline, which means that the users can't access the emails while it is moved. No roll-back support – If something goes wrong you may need to go back to tape to restore the mailbox No support for native tools – if they don't work they don't work. No Outlook client profile automation for migrated mailboxes. No automatic enabling of RPC encryption for Outlook 2003 based clients. You will need to do them manually or you will need to disable RPC encryption on Exchange 2010 (not recommended) No Public Folder migration tools No distribution group migration tools You can't move mailboxes if running Exchange 2003 SP1 or earlier, you must update all servers to 2003 SP2+ You can't perform message tracking configuration tasks between Exchange 2010 and Exchange 2003 You must use Exchange 2003 messaging tracking tools within your Exchange 2003 organization, and Exchange 2010 messaging tracking tools within your Exchange 2010 Side-by-side management for Exchange Server 2003 and Exchange 2010 management tools isn't supported, because Exchange Server 2003 management tools can only be run on 32-bit machines In order to do Cross-forest move requests must create mail-enabled users with the required attributes in the target forest or it won't work Depending on the scenario you just may be able to preserve mailbox folder delegates and send-on behalf of delegates If upgrading, you must run the setup /PrepareLegacyExchangePermissions command so that the Exchange 2003 Recipient Update Service functions correctly If upgrading, you are required to update the Active Directory schema for Exchange Server 2010 If upgrading, you must Upgrade Custom LDAP Filters to OPATH Filters Exchange 2007 to 2010 You can use 2010 console or "move request" cmdlets in 2010 shell to move the mailboxes. If you implement Exchange 2010 in mixed mode, some features of Exchange 2010 will not be available until the migration is completed and the organization in moved to a native mode state. Move requests are performed by the Microsoft Exchange Mailbox Replication Service (MRS) that runs on all Client Access servers (CAS). Therefore, CAS servers are busy moving mailboxes and not servicing clients' requests. You can't use "move-mailbox" cmdlet in 2007 shell. No roll-back support – If something goes wrong you may need to go back to tape to restore the mailbox No support for native tools – if they don't work they don't work. The mailbox move is online, which means that the users can be online while the move happens. You can't move mailboxes from 2007 SP1 or earlier, the source should run 2007 SP2+ Exchange 2007 Mailbox databases can't be managed from the EMC in Exchange 2010 No Public Folder migration tools No distribution group migration tools No Outlook client profile automation for migrated mailboxes. No automatic enabling of RPC encryption for Outlook 2003 based clients. You will need to do them manually or you will need to disable RPC encryption on Exchange 2010 (not recommended) The EMC in Exchange 2010 can't manage Exchange 2007 mobile devices Exchange 2007 Mailbox databases can't be managed from the EMC in Exchange 2010 You can't use message tracking configuration tasks between Exchange 2010 and Exchange 2007 You must use Exchange 2007 messaging tracking tools within your Exchange 2007 servers, and Exchange 2010 messaging tracking tools within your Exchange 2010 servers. Exchange 2010 and Exchange 2007 servers can only be viewed from their corresponding version of the EMC In order to schedule Cross-forest move requests must create mail-enabled users with the required attributes in the target forest or it won't work If upgrading, you are required to update the Active Directory schema for Exchange Server 2010 Depending on the scenario you just may be able to preserve mailbox folder delegates and send-on behalf of delegates Exchange 5.5 and 2000 to 2010 Not supported by Exchange 2010 native tools If you want to move to Exchange 2010 using native tools from Exchange 5.5 you must first migrate to Exchange 2003/2007 then to Exchange 2010 If you want to move to Exchange 2010 using native tools from Exchange 2000 you must first migrate to Exchange 2003/2007 then to Exchange 2010 In short, it's not as simple as tossing in a CD. Can it be done? Sure, would we want to do it? Nope. We highly recommend you consider the resource forest model for Exchange 2010 to avoid trying to mix the old with the new. This model, in our opinion, allows the most flexibility during migration, allows you to build your Exchange organization to your needs, and provides benefits well into the future. It also helps to reduce risk. Something we all like! This is not a complete list of issues nor should it be used as a roadmap to moving to Exchange 2010. We are providing this simply as a comparison and we do not take any responsibility whatsoever for the information contained. You are encouraged to do your own due diligence and research. And no animals were harmed in the writing of this post Posted May 20 2010, 08:23 PM by Priasoft with 1 comment(s) Filed under: options, Exchange 2010, Exchange Server, Resource Forest, Migration, Exchange 5.5

• Exchange Adoption Patterns

  Despite the advantages of moving to Exchange Server 2010, will organizations using an old software product want to upgrade to a newly-released version? It all depends on the organization type (see Figure 1). There are different organization types when it comes to adopting software: Early adopters jump onto the software bandwagon as soon as the software is released. Needless to say, they are far and few between and will usually have a special relationship with the software manufacturer. Common adopters wait for others to test the software release and find all of its potential bugs. This usually coincides with the release of the first service pack for the software product. Conservatives will wait well after the software has been released, often after the release of multiple service packs, before they make their move. Ultra-conservatives will wait until the very last minute before they move to the next version of the product and when they do, they won't usually jump onto the very latest version of the product. This cycle is repeated every time a new version of a product is released. Regardless of which version your choose we have the tools and experience to move you from Exchange 5.5, 2000, 2003, and 2007 to Exchange 2000, 2003, 2007, and even 2010… Posted May 20 2010, 03:26 PM by Priasoft with no comments Filed under: Exchange Server, Migration

• So you’re still on Exchange 5.5, huh?

  Organizations which are still using Exchange 5.5 at this point are obviousy reluctant to move a mission-critical communication system, especially one that just works, to Exchange 2010. That's because there is no direct Microsoft-supported upgrade path from Exchange 5.5 to Exchange Server 2007 or Exchange 2010. Organizations wishing to make the move from Exchange 5.5 to Exchange Server 2007 or 2010 must either perform an interim upgrade to Exchange Server 2003 (and then to 2007 if you want to finish on 2010) prior to upgrading to 2007 or must rely on a third-party utility to jump directly. But don't feel bad. There is no direct upgrade path to Exchange Server 2007 from any version of Exchange Server! That's right. Because Exchange Server 2007 runs on 64-bit hardware and requires an x64 Edition of Windows Server to run, Microsoft does not support the actual upgrade of a server running Exchange. In fact, Microsoft is introducing two new terms to its Exchange upgrade policy: transition and migration. Transition means upgrading an Exchange organization as a whole to Exchange Server 2007. To do this, you have to move the data from your existing servers to new servers running version 2007 or 2010. You basically add new 2007/2010 servers, join the existing organization, move the data and then, decommission your old servers. Migration means moving from an existing organization to a brand new 2007 or 2010 organization. For this, you need to install new Exchange servers into a new, clean organization, then move mailboxes and data from the old organization to the new organization. Once the move is complete, you can then decommission the old servers and delete the old organization. Also see http://community.priasoft.com/blogs/exchange_migration_team_blog/archive/2010/05/20/using-a-dedicated-exchange-forest-resource-forest.aspx for why we think using a resource forest is a great option. There is a lot to be said for both methods, though if you can use it, the transition method is simpler than the migration method if you are trying to use the native tools. The main advantage of the migration method is that you get the opportunity to completely revamp your Exchange organization. If there are aspects of the existing organization you don't like, then this might be the best method for you. If you're at 5.5 today, then you can use either method, but you have to use an intervening step—a move to Exchange 2003 and then to Exchange 2007—especially if you choose to rely on the tools Microsoft provides. There are other choices though. Tried and tested, the Priasoft Migration Suite for Exchange can help make upgrading from Exchange 5.5 to Exchange Server 2007 or directly to Exchange 2010 a snap. The Priasoft Migration Suite for Exchange (www.priasoft.com), can assist during every step of the upgrade process. In addition, it can assist with everything from pre-migration planning to migrating account information to Active Directory to client profile migration. In fact, Priasoft Migration Suite is in its Sixth edition and has assisted organizations in migrating millions of mailboxes to date. This has helped them ensure that every step of the migration process is covered. In fact, this suite supports the ten-step migration process: It assists in the gathering of information in support of a migration business case. It supports new Exchange features and helps map out existing content to those features. It provides an inventory of existing Exchange organizations to display information on what needs to be migrated. It helps you redesign your Exchange structures to help improve service levels. It provides support for the creation of the new Exchange architecture. It provides test migration modes to let you make sure you have the steps down pat. It lets you move to the new organization in multiple steps, letting you manage the migration at your own pace. It gives you time to restructure how you will manage the new organization which helps provide training time for your administrators and technicians. It lets you notify users when the migration process is about to occur and after it has been completed to make sure they are completely aware of where you are and how it affects them. Once the migration is complete, it can provide ongoing support for potential future mergers and/or acquisitions. Using a third-party tool is an excellent option today because of the fact that organizations running 5.5 must perform at least two migration steps to get from 5.5 to 2007 or 2010. Posted May 20 2010, 03:16 PM by Priasoft with no comments Filed under: Exchange Server, Migration, Exchange 5.5

• Exchange 2010 servers with no Internet Access.. Timeout Issues

  Exchange services timeout or long wait times for services or application to start up. This problem occurs when a server has no internet access or occasionally when a server has limited internet access. The cause of this problem is likely related to a routine check of the Certificate Revocation List (CRL) for .NET assemblies. In this post, I will provide some details regarding how CRL check affects Exchange server services and applications and how some registry settings can contribute to the problem (and solution). See here for more information Posted May 20 2010, 02:51 PM by Priasoft with no comments Filed under: Problem, Exchange 2010

• Using a Dedicated Exchange Forest (Resource Forest)

  Often, setting up a separate Active Directory forest that is dedicated to running Exchange is a better solution than integrating the Exchange application into your production Active Directory security forest. The Exchange forest (also known as the resource forest) is dedicated to running Exchange and hosting mailboxes. User accounts are contained in one or more forests, referred to as the account forests, which are separate from the resource forest. Using this model, updates and changes to Exchange can be made without affecting the production user account forests. See Example Image How it works: The user from the account forest is associated with a mailbox attached to a disabled placeholder user in the resource forest. This allows users to access mailboxes that reside in the Exchange resource forest. In this scenario, you configure a trust between the resource forest and the account forest(s). A few key Benefits: A dedicated security boundary between Active Directory and Exchange administration. You can move to new versions of Exchange, like Exchange 2010, without polluting, corrupting, or disrupting your existing production Exchange implementation Eliminates risk to your existing Exchange implementation You can manage users and groups in a way the makes sense for Exchange and not be dependent on how users in the account forest are managed If you merge with another entity it's simply a matter of creating a trust with the new accounts forest and not having to disrupt the exchange organization If you divest part of your business entity's its much simpler to break off the Exchange resources without giving away sensitive security objects that would be part of the User Domains. Schema modifications needed for Exchange are isolated to just the Exchange forest and do not need to be implement in the Accounts forest Less stress on Global Catalogs and directory replication in the user accounts forest as all this traffic can remain in the Exchange resource forest Features of new platform are realized immediately compared to a 'mixed-mode' setup where some key features are always disabled during the mixed-mode phase. Patches and updates that are not Exchange related, do not have to be installed in the Exchange forest.  This adds a level of stability that is unavailable in a mixed AD/Exchange forest. AD container and OU structure can be designed with Exchange Administration in mind and does not have to follow complex architecture of a user forest Distribution lists are not co-mingled with security because of separate forests.  DLs in the Exchange forest can be guaranteed to only provide access to exchange resources. Prerequisites You have the following two Active Directory forests: One forest contains the user accounts for your organization. In this procedure, this forest is called the accounts forest. One forest does not contain user accounts and does not yet have Exchange installed. In this procedure, this forest is called the Exchange forest. You will use the procedure to install Exchange 2010 in this forest. You have correctly configured Domain Name System (DNS) for name resolution across forests in your organization. To check that you have DNS configured correctly, ping each forest from the other forest or forests in your organization. For more detailed information on deploying an Exchange resource forest see the following: Exchange 2010 resource forest Exchange 2007 resource forest Exchange 2003 resource forest   Posted May 20 2010, 02:08 PM by Priasoft with 2 comment(s) Filed under: Exchange 2010, Exchange Server, Resource Forest, Migration, Exchange 5.5